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ABSTRACT 


Research  Report 

The  assurance  of  the  safety  or  security  of  critical  software  rests  on  a  clear  understanding 
of  the  formal  semantics  of  the  programming  language  used.  Operational  semantics  is 
the  most  widely  used  means  of  formally  defining  a  language.  The  need  for  high  levels  of 
assurance,  along  with  the  complexity  of  these  definitions  for  real  programming 
languages,  means  that  tool  support  is  essential  for  carrying  out  reasoning  about  code 
with  respect  to  the  language  definition. 

In  this  paper,  we  describe  a  generic  approach  to  automated  reasoning  about  the 
operational  semantics  of  programming  languages.  As  an  application  of  this  approach, 
we  describe  the  construction  of  an  environment  for  reasoning  about  programs  written  in 
a  functional  subset  of  ML.  The  system  we  describe  (called  Elle)  captures  the  formal 
operational  semantics  definition  of  a  large  subset  of  Standard  ML  within  the  theorem 
prover  Isabelle,  and  provides  some  support  for  the  verification  of  ML  programs. 
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1  Introduction 

The  work  described  in  this  paper  is  motivated  by  the  general  problem  of  assuring 
the  safety  or  security  of  critical  software,  in  which  a  single  error  could  have  disastrous 
consequences.  In  such  software,  the  conventional  methods  of  validation  (such  as  testing) 
are  not  sufficient  to  give  the  required  assurance.  They  must  be  complemented  with 
verification  activities  which  provide  formal  proofs  of  the  correctness  of  the  code  with 
respect  to  its  (formally  specified)  critical  requirements. 

The  verification  of  code  requires  a  clear  understanding  of  the  role  of  the  formal  semantics 
(i.e.  meaning)  of  the  programming  langauge  in  question.  Clearly,  knowledge  of  the 
precise  meaning  of  a  program  must  be  a  precursor  to  any  formal  statements  about  the 
correctness  of  the  program.  The  formal  semantics  of  the  language  is  ‘important  even 
for  negotiators  and  contractors,  for  a  robust  program  written  in  an  insecure  language  is 
like  a  house  built  upon  sand.’  [1].  The  work  reported  on  here  has  arisen  directly  from 
the  desire  to  explore  the  role  of  formal  semantics  in  the  verification  process. 

The  most  widely  used  approach  to  formal  semantics  today  is  that  of  operational 
semantics  [2,  3],  The  semantics  is  given  as  a  number  of  inference  rules  which  describe 
under  what  conditions  a  language  construct  will  evaluate  to  a  particular  value.  This 
method  of  language  definition  is  a  useful  guide  for  the  implementer  of  an  interpreter 
or  compiler  for  the  language.  It  is  especially  useful  for  describing  the  semantics  of 
concurrent  languages  and  process  algebras  [4,  5],  where  the  denotational  semantics 
may  be  technically  difficult  and  less  easy  to  mechanise. 

The  operational  semantics  definition  of  a  programming  language  can  be  quite  extensive, 
and  cumbersome  to  work  with.  Because  of  this,  tool  support  is  useful  for  understanding 
and  managing  such  definitions;  it  is  essential  if  one  wishes  to  carry  out  reasoning  about 
programs  according  to  the  definition. 

In  this  paper,  we  describe  a  generic  approach  to  automated  reasoning  about  the  op¬ 
erational  semantics  of  programming  languages.  A  method  for  capturing  operational 
semantics  definitions  is  described  in  detail  for  the  Isabelle  theorem  prover  [6]. 

The  best-known  example  of  a  language  which  is  fully  defined  via  a  formal  operational 
semantics  is  Standard  ML  [1].  The  programming  language  ML  (ML  stands  for  Meta- 
Language),  was  originally  developed  during  work  on  the  early  theorem  prover  LCF  [7, 
8].  Although,  to  our  knowledge,  ML  has  not  yet  been  used  in  critical  software  projects,  it 
has  nevertheless  evolved  to  the  point  where  it  is  an  important  programming  language  in 
its  own  right,  expressive  enough  for  many  real  applications,  and  with  numerous  desirable 
features  (such  as  strong  typing,  exception  handling  and  modules)  which  modem  software 
engineering  and  critical  software  development  require. 

In  this  paper  we  therefore  describe,  as  a  significant  application  of  our  approach,  the 
construction  of  a  verification  environment,  called  EUe,  for  reasoning  about  Standard 
ML  programs.  We  chose  a  substantial  subset  of  this  language,  namely  the  functional 
subset  of  the  Core  of  SML  (we  shall  denote  this  language  by  T).  The  system  captures 
the  formal  operational  semantics  definition  of  T  within  Isabelle.  Both  the  static  (type¬ 
checking  or  elaboration)  and  the  dynamic  (evaluation)  semantics  of  T  are  incorporated. 
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Simple  proof  procedures  can  prove  7  programs  correct  by  inferring  the  result  of 
evaluation  or  elaboration  demanded  by  the  definition  of  SML.  The  work  will  benefit 
those  trying  to  understand  the  definition,  and  experts  who  wish  to  explore  possible 
modifications  and  extensions. 

The  approach  described  in  this  paper  is  applicable  to  any  language  defined  via  its 
operational  semantics.  In  future  work,  it  is  planned  to  describe  the  application  to  the 
problem  of  automated  reasoning  about  programs  in  process  algebras  such  as  CCS  [9] 
and  CSP  [10].  The  method  is  equally  applicable  to  reasoning  about  properties  of  formal 
specifications  in  languages  such  as  Z,  whose  semantics  can  be  described  by  a  proof 
theory  such  as  W  [11]. 

The  rest  of  this  paper  is  structured  as  follows.  In  Section  2,  we  describe  our  general 
approach  to  reasoning  about  operational  semantics.  In  Section  3  we  give  a  brief 
overview  of  the  Isabelle  theorem  prover  [6],  and  describe  in  Section  4  how  our  method 
is  captured  within  Isabelle.  We  then  give  in  Section  5  a  description  of  some  aspects 
of  set-theoretic  reasoning  in  Isabelle  which  are  necessary  for  our  work.  The  rest  of  the 
paper  describes  the  particular  application  to  reasoning  about  Standard  ML  (SML).  In 
Section  6  we  describe  the  structure  of  the  Definition  of  SML.  The  following  sections 
(Sections  7  to  11)  give  a  detailed  description  of  the  Elle  system.  Finally,  Section  12 
discusses  the  results  and  give  suggestions  for  further  work. 


2  Reasoning  About  Operational  Semantics 

2.1  Introduction 

An  operational  semantics  definition  for  a  programming  language  is  an  instance  of  a 
transition  system  [3],  which  is  a  pair  (f,  =>),  where  F  is  a  set  of  configurations,  and  =4- 
is  a  relation  on  /\  with  the  interpretation  that  7 j  =$>  7 2  means  that  7 1  evaluates  to  7 2. 

Suppose  that  L  is  a  context-free  language  [12],  described  by  a  context-free  grammar 
G  =  (V,T ,  P),  where: 

•  V  is  a  finite  set  of  nonterminals 

•  T  is  a  finite  set  of  terminals  (V  fl  T  —  0  ) 

•  P  is  a  finite  set  of  productions,  each  production  n  being  of  the  form  v  —>  a, 
where  v  e  V  and  a  is  a  string  of  symbols  from  ( V  U  T )* 

We  shall  further  suppose  that  we  have  a  set  I  =  {id} , i<4},  with  IQ  T,  of  identifier 
symbols. 

The  (operational)  semantics  of  the  language  L  is  given  as  follows.  Firstly,  the  relevant 
semantic  objects  must  be  prescribed.  These  will  be  mathematically  well-understood  sets 
or  functions,  and  are  the  domains  in  which  the  meaning  of  the  language  will  be  defined. 
We  have  a  number  of  simple  semantic  objects,  from  which  certain  compound  semantic 
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objects  are  built,  via  standard  set-  or  function-theoretic  operations: 

Ax  B  (Cartesian  Product) 

B  (Finite Maps) 

A  U  B  (Disjoint  Union) 
f  \  g  (Overwriting) 

For  each  production  7 r  of  G,  with  7r  of  the  form  v  — >  a,  we  associate  a  formula 
C  h  a  =>  C'  called  a  sequent.  The  interpretation  of  this  sequent  is  as  follows.  When  we 
evaluate,  i.e.  compute  the  meaning  of,  the  phrase  a  against  the  semantic  background 
represented  by  the  collection  C  of  semantic  objects,  we  obtain  the  result  C'.  In  general 
C'  itself  can  be  a  collection  of  semantic  objects. 

The  circumstances  under  which  we  can  infer  the  truth  of  this  sequent  are  described  by 
a  collection  of  inference  rules  R,x  (1  <  i  <  n)  of  the  form: 

_  Condf  ...  Condi' 

*  C  h,  a  =£>  C’ 

where  the  premises  Condj  are  either  sequents  or  side- conditions,  i.e.  other  formulae 
involving  semantic  objects. 

2.2  Requirements 

In  constructing  a  system  for  machine-assisted  reasoning  about  programs  in  the  language 
L,  our  aim  is  to  capture  the  syntax  and  formal  operational  semantics  in  as  natural  a  way 
as  possible  in  a  suitably  powerful  theorem  prover. 

There  are  three  general  kinds  of  proof  activity  which  we  wish  to  be  able  to  automate, 
as  follows. 

•  Evaluation  of  Phrases.  Here  we  wish  to  discover  the  result  of  an  evaluation 
in  accordance  with  the  semantics.  We  do  this  by  asserting  the  goal  to  be 
proved  in  the  form 

C\~v  a  ■=$■  1C1 

where  1C  is  a  scheme  variable  for  the  as-yet  unknown  result  of  evaluation. 
It  will  be  instantiated  during  the  proof. 

•  Proofs  of  Correctness.  Here  the  goal  is  of  the  form 

C  h,  a  =>•  C1 

with  the  result  already  believed  known;  other  sequents  or  side  conditions  may 
also  be  involved  as  assumptions  in  the  proof. 

•  Reasoning  About  Equivalences.  We  wish  to  be  able  to  establish  equivalences, 
where  we  say  that  two  phrases  a  and  a’  are  equivalent  if  they  evaluate  to  the 
same  result  in  every  semantic  background,  i.e. 

(C  hr  ct  =r>  C’)  ^  (C  hy  a’  ^  C1) 
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We  shall  now  address  specific  requirements  which  need  to  be  met  by  the  theorem  prover. 

2.2.1  Language  Requirements 

2.2. 1.1  Genericity 

The  method  must  be  generic,  i.e.  the  basic  idea  should  be  applicable  across  a  range 
of  languages. 

2. 2. 1.2  Concrete  Syntax 

It  is  highly  desirable  that  the  theorem  prover  chosen  should  allow,  as  far  as  possible, 
the  concrete  syntax  of  L  to  be  faithfully  represented.  The  same  requirement  holds 
for  semantic  objects.  Reasoning  about  language  semantics  is  already  a  difficult  and 
challenging  activity;  it  should  not  be  impeded  by  having  proofs  presented  in  an 
unfamiliar  or  even  unreadable  syntax.  Having  a  reasonably  clean  concrete  syntax, 
which  is  also  strictly  maintained  during  a  proof,  is  a  great  aid  to  understanding. 

2. 2. 1.3  Derived  Forms 

A  language  will  often  have  a  number  of  derived  forms,  namely  syntactically  “new” 
language  constructs  which  are  mere  surface  syntax  for  more  primtitive  constructs.  (Such 
derived  forms  are  important  in  SML).  There  are  no  inference  rules  for  these  derived 
forms;  they  will  always  be  reduce  to  the  primitive  constructs.  The  prover  should 
support  the  use  of  derived  forms. 

2.2.2  Semantic  Requirements 

2.2.2. 1  Support  for  Semantic  Objects 

An  expressive  (and  preferably  familiar)  object-logic  will  be  needed  to  capture  the  basic 
properties  of  semantic  objects. 

2.22.2  Support  for  Meta-Level  Reasoning 

The  above  inference  rules  are  used  in  practice  both  as  introduction  rules,  in  which  we 
attempt  to  establish  the  truth  of  the  sequent  C  h„  a  =>  C',  or  as  elimination  rules,  in 
which  this  sequent  is  given  as  an  assumption,  and  we  reason  that  it  must  have  been 
inferred  via  R,  (for  some  i).  The  latter  is  an  instance  of  meta-level  reasoning.  If  we 
wish  to  be  able  to  carry  out  the  most  general  reasoning  about  programs  in  the  language  L 
—  such  as  proofs  of  correctness,  transformations,  equivalences  etc  —  then  our  method 
will  need  to  be  able  to  express  inference  rules  in  such  a  way  that  the  effect  of  applying 
the  corresponding  introduction  and  elimination  rules  can  easily  be  achieved. 

2.22.3  Logical  vs  Program  Variables 

We  shall  need  to  be  able  to  mix  program  variables  (which  are  part  of  the  language)  and 
logical  variables  (used  for  quantifying  over  language  phrases  and  semantic  objects),  and 
have  a  way  of  distinguishing  between  them. 
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2.2.3  Proof  Requirements 

2.2.3. 1  Tactic  Language 

The  theorem  prover  should  support  goal-directed  proofs  by  means  of  tactics ,  and  it 
should  be  easy  to  built  new  tactics  from  existing  ones.  Subtle  proof  procedures  are 
necessary;  thus,  the  language  of  tactics  should  also  be  sufficiently  expressive. 

2. 2. 3. 2  Powerful  Proof  Heuristics 

Ideally,  the  theorem  prover  should  have  built-in  powerful  automated  proof  methods 
which  apply  Artificial  Intelligence  techniques  of  search,  attempts  at  proofs  by  induction 
etc.  These  are  called  heuristics. 

2.2.3.3  Backtracking  Search 

The  language  inference  rules  often  allow  a  particular  sequent  to  be  inferred  in  more 
than  one  way.  In  a  particular  goal-directed  proof,  the  chosen  theorem  prover  will  need 
to  be  able  to  manage  multiple  (possibly  infinitely  many)  proof  states,  and  to  back  up 
if  the  wrong  branch  of  the  proof-tree  is  chosen. 

2.2.3.4  Answer  Extraction 

It  will  be  important  to  have  the  facility  (as  Prolog  does)  for  answer  extraction  during 
a  proof:  for  example,  we  may  wish  to  establish  the  truth  of  the  sequent  C  \~v  a  =$-  C' 
without  knowing  in  advance  all  of  the  semantic  objects  C  and  C'. 


2.2.3. 5  Recursive  Domains 


Ideally,  the  prover  should  support  reasoning  about  recursive  functions  and  datatypes, 
allowing  the  automatic  production  of  induction  theorems,  cases  theorems  etc. 

2.2.4  User  Interface 

Clearly  it  is  desirable  to  use  a  theorem  prover  with  a  user-interface  that  makes  the 
theory  building  and  theorem-proving  tasks  as  straightforward  as  possible.  Most  theorem 
proving  tools  have  primitive  user-interfaces;  however,  recent  advances  in  graphic 
user  interface  technology  have  meant  that  simple  window-based  interfaces  are  under 
development  for  most  pro  vers. 

2.3  Discussion 

Based  on  the  above  requirements,  we  surveyed  a  number  of  theorem  provers,  of 
which  four  were  chosen  as  indicative:  namely,  Isabelle  [6],  Mural  [13],  HOL  [14]  and 
EVES  [15].  (Prolog  has  been  used  for  the  purpose  [16].  However,  we  have  ruled  it 
out,  because  it  fails  to  meet  most  of  the  above  requirements.) 
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The  following  table  summarises  whether  or  not  the  requirements  are  met  for  these 
provers.  It  can  be  seen  from  the  table  that,  although  HOL  is  a  highly  expressive  system 


Table  1  Properties  of  Theorem  Provers 


Isabelle 

Mural 

HOL 

EVES 

Generic 

Yes 

Yes 

No 

No 

Concrete 

Syntax 

Yes 

Yes 

No1 

No 

Derived  Forms 

Yes 

No 

No 

No 

Suitable 

Object-Logic 

Yes  (ZF  or 
HOL) 

Yes  (VDM 
Logic  and 

Data) 

Yes  (HOL 
itself) 

Yes  (Verdi) 

Meta-Level 

Reasoning 

Yes 

Yes 

Yes 

Yes 

Logical 

Variables 

Yes 

Yes 

Yes 

Yes 

Tactic 

Language 

Yes,  flexible 

Yes,  not  so 
usable 

Yes,  flexible 

No 

Proof 

Heuristics 

Fair 

Fair 

Limited 

Very  Good 

Search 

Yes 

Yes  (rarely 
used) 

No 

Yes  (built-in) 

Answer 

Extraction 

Yes 

No 

No 

No 

Recursive 

Domains 

Yes 

Yes 

Yes 

Yes 

User  Interface 

Basic 

Windows 

Basic 

Basic 

with  a  large  user  base,  it  does  not  meet  our  requirements  for  features  such  as  concrete 
syntax,  derived  forms,  answer  extraction  and  backtracking  search.  Likewise,  the  EVES 
system,  in  many  ways  the  ‘state-of-the-art’  in  powerful  theorem-proving  tools,  again 
does  not  have  the  facilities  for  concrete  syntax,  derived  forms  and  answer  extraction, 
and  its  search  facility  is  not  customisable.  Thus,  our  choice  of  theorem  prover  can 
really  be  narrowed  down  to  two  possibilities,  namely  Isabelle  and  Mural.  Mural  has 
an  excellent  user  interface  which  allows  concrete  syntax.  This  alone  would  make  it  a 
serious  candidate;  however,  it  lacks  the  facilities  of  derived  forms,  answer  extraction, 
expressive  tactic  language,  and  the  search  facility  is  rudimentary. 

Isabelle  was  chosen  for  our  work,  because  it  meets  all  the  essential  requirements.  In 
the  next  Section,  we  shall  give  an  overview  of  Isabelle. 

1  Note  that  HOL  90,  an  implementation  in  SML,  does  allow  concrete  syntax 
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3  Isabelle 

3.1  Introduction 

Isabelle  has  been  under  development  by  Larry  Paulson  and  collaborators  at  the  Uni¬ 
versity  of  Cambridge  since  1986  [6,  17,  18].  It  is  a  member  of  the  LCF  family  [8]  of 
tactical  theorem  provers,  and  is  written  in  Standard  ML. 

Isabelle  is  a  generic  proven  the  logic  of  discourse  ( object  logic )  may  be  defined  by  the 
user,  or  chosen  from  one  of  the  object  logics  provided  with  the  system.  Isabelle  also 
has  an  expressive  meta-logic,  in  which  the  inference  rules  and  axioms  of  these  object 
logics  can  be  formulated.  Isabelle  allows  concrete  syntax,  and  supports  derived  forms 
via  user-provided  parse  and  print  translations. 

Semantic  objects  can  be  comfortably  described  within  various  possible  object  logics: 
the  most  natural  choice  is  Isabelle’s  Zermelo-Fraenkel  (ZF)  Set  Theory.  Meta-level 
reasoning  (i.e.  the  two-way  nature  of  operational  semantics  inference  rules)  can  easily 
be  captured  within  these  logics,  as  will  be  seen  later.  Logical  and  program  variables 
can  be  handled. 

Isabelle  supports  both  forwards  proof,  and  backwards  (goal-directed)  proof  using  tactics; 
it  has  a  subgoal  package,  for  manipulating  proofs  interactively.  Isabelle  lacks  the 
powerful  proofs  commands  found  in  the  EVES  system,  but  it  is  straightforward  to  write 
appropriate  proof  procedures  using  the  Isabelle  tactic  language.  New  tactics  can  be 
constructed  from  existing  ones  by  means  of  tacticals.  Various  search  tactics  can  be 
constructed.  Answer  extraction  during  proofs  is  made  possible  by  Isabelle’s  scheme 
variables. 

Recursive  datatypes  and  functions  can  be  defined  by  means  of  the  machinery  of  least 
fixed  points,  developed  recently  by  Paulson  for  the  ZF  and  HOL  logics  [19]. 

A  window-based  interface  for  Isabelle  is  not  yet  generally  available,  but  an  interface 
based  on  the  Centaur  system  [20]  has  been  developed  by  Laurent  Thdry  at  the  University 
of  Cambridge  [21].  A  window-based  interface  called  Xlsabelle,  implemented  using 
the  PolyML/Motif  [22]  system,  is  also  being  developed  at  DSTO  by  the  authors. 
This  interface  offers  theory  browsing  facilities,  and  provides  advice  to  the  user  about 
applicable  matching  rules  during  interactive  proofs.  The  interface  is  described  in  [23]. 

In  this  section  we  shall  briefly  describe  the  various  aspects  of  Isabelle  (meta-logic, 
object  logics  and  their  theory  files,  forwards  and  backwards  proof,  tactics  and  tacticals). 

3.2  The  Meta-Logic 

The  meta-logic  must  be  compact,  but  expressive  enough  to  be  able  to  formulate  the 
rules  and  axioms  for  object  logics.  Isabelle’s  meta-logic  is  intuitionistic  higher-order 
logic  with  universal  quantification  and  equality,  and  a  type  system  with  order-sorted 
polymorphism.  Pure  Isabelle  implements  the  meta-logic. 

The  tables  below  show  the  constructs  used  in  the  meta-logic  {types,  terms  and  formulae). 
Examples  appear  in  the  rest  of  this  Section. 
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Table  2  Notation  for  Types 


Notation 

Description 

7 -  C 

class  constraint 

a  =>  r 

function  type 

curried  function  type 

((Ji ,  <7n)  tyop 

type  construction 

Table  3  Notation  for  Terms  (typed  A-calculus) 


Notation 

Description 

t  ::  a 

type  constraint 

A  x.<f> 

meta-abstraction 

t^Ul  ,  ....  tffj) 

application 

Table  4  Notation  for  Meta-Formulae 


Notation 

Description 

a  =  b 

meta-equality 

<j>  =>  tl> 

meta-implication 

[<f>\\  —<£n ]  => 

nested  implication 

A  x.cf) 

meta-quanti  fi  cati  on 

3.3  Object  Logics  and  Theories 

An  object  logic  is  an  ML  object  of  type  theory.  The  axioms  and  rules  are  of  type  thm. 
Isabelle  comes  provided  with  a  number  of  object  logics,  including  First  Order  Logic 
(FOL),  Zermelo-Fraenkel  Set  Theory  (ZF)  and  a  version  of  Higher-Order  Logic  (HOL). 

Isabelle  works  with  inference  rules  expressed  in  a  natural  deduction  style.  Each  logical 
connective  has,  in  general,  elimination  and  introduction  rules  of  inference.  For  example, 
Table  5  shows  examples  of  these  rules  for  conjunction  and  implication  in  first-order 
logic. 


8 


DSTO-RR-0008 


Table  5  Examples  of  Inference  Rules 


Introduction  (I) 

Elimination  (E) 

Conjunction 

A  B 

A  AB 

AAB 

AAB 

A 

B 

Implication 

[A]  B 

Ad  B  A 

Ad  b 

B 

Note  that  the  rule  for  implication  elimination  is  just  modus  ponens.  In  the  meta-logic, 
it  is  expressed  (using  nested  meta-implication)  as  follows: 

[A;AdB]^B 

In  Isabelle,  theories  are  most  easily  specified  by  means  of  theory  files  [6].  A  theory  file 
declares  the  parents  of  the  theory  in  question,  new  classes  and  types  and  new  constants 
along  with  their  types  and  concrete  syntax.  It  then  gives  definitions  (via  meta-equality), 
axioms  and  inference  rules  for  the  logic.  The  theory  file  may  also  include  some  derived 
forms,  given  by  means  of  parse  and  print  translations.  Once  these  translations  have 
been  provided,  we  can  use  the  derived  forms  freely  in  goals,  and  they  will  be  correctly 
dealt  with. 

3.4  Forwards  Proof 

Isabelle  allows  new  theorems2  to  be  created  by  resolution.  In  general,  suppose  we  have 
two  theorems  of  the  form: 


\Ai ; Am]  A 
[Bj;...;B„]  =>  B 

where  A  unifies  with  Bj,  so  there  is  a  substitution  s  such  that  s(A)  =  s(B;).  Then,  by 
resolution,  we  have  a  new  theorem: 

s{[Bi  >  •••>  Bi—i ;  Ai ; ...;  Am ;  Bi+i ; ...;  Bn ]  =£■  B) 

For  example,  from  the  two  theorems 


P  A  Q  =$■  P  (conjunctl) 
P  =$  P  V  Q  (disjll) 

we  can  use  resolution  to  obtain  the  theorem  : 

P  a  Q  =*>  PV  Q 


2 


Note  that  in  Isabelle  ‘theorem’  includes  inference  rules  and  definitions  in  the  object-logic. 
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3.5  The  Subgoal  Package 

Isabelle  carries  out  goal-directed  proofs,  and  contains  a  subgoal  package  to  assist  with 
interactive  proof.  A  proof  state  consists  of  a  goal,  along  with  a  number  of  subgoals 
whose  validity  establishes  that  of  the  goal.  The  subgoals  can  be  thought  of  as  proof 
obligations.  Diagrammatically  we  display  a  proof  state  as  follows: 

initial  goal 
subgoaf  ...  subgoaln 

When  we  set  a  goal  in  Isabelle  we  have  as  our  initial  proof  state 

goal 

goal 

in  which  there  is  a  single  subgoal  identical  with  the  original  goal.  A  proof  state  with 
no  subgoals  is  a  proof  of  the  original  goal. 

3.6  Basic  Tactics 

Proof  states  are  transformed  to  new  states  by  means  of  the  application  of  tactics.  In 
Isabelle  a  tactic  may  fail,  or  return  one  or  more  new  proof  states,  possibly  a  lazy 
infinite  list. 

In  general,  if  T  is  a  tactic,  and  <j>  a  proof  state,  then  the  result  T<f>  of  applying  T  to  <f> 
is  written  as  a  list  to  capture  the  various  alternatives: 

T(j)  =  [  ]  (failure) 

T (j>  =  [ip]  (unique  result) 

T<p  =  [tpi  ,ipz,ip3,  •••]  (multiple  outcomes) 

If  the  tactic  succeeds,  the  head  of  this  list  is  the  active  proof  state,  and  is  usually 
presented  with  all  of  its  subgoals  shown.  Many  tactics  act  on  a  number  of  subgoals, 
automatically  instantiating  variables  and  renumbering  the  subgoals  as  appropriate. 

Pure  Isabelle  has  a  number  of  commonly  used  basic  tactics  (object  logics  also  have 
their  own  special  purpose  tactics).  We  shall  discuss  the  most  important  of  these. 

Recall  that  Isabelle  emphasises  the  natural  style  of  reasoning;  correspondingly,  most 
proof  steps  are  carried  out  backwards  reasoning  using  inference  rules  of  the  logic.  This 
is  called  resolution.  Isabelle  provides  a  single  ML  function  to  do  this. 

The  basic  resolution  tactic  is  resoive^tac  thms  i.  This  tactic  tries  each  theorem  in  the 
list  thms  against  subgoal  i  of  the  proof  state,  until  a  rule  is  found  whose  conclusion  can 
unify  with  the  subgoal.  For  a  given  rule,  say 

[Br,...;Bk]  =*•  B 


and  subgoal 


\Ai ; ...;  An\  =£•  A 
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where  A  can  unify  with  B  under  the  substitution  s,  resolution  replaces  A  by  the 
instantiated  premises  Bi , producing  a  new  state  with  the  following  subgoals: 

s([Ai] ... ;  An]  =>  'WP) 
i  •••»  An]  ~Bk) 

in  which  the  instantiations  resulting  from  the  substitution  s  have  been  made. 

Subgoals  frequently  change  their  appearance  as  instantiations  propagate  throughout  the 
proof  tree. 

Multiple  outcomes  can  arise  in  two  ways.  Firstly,  unification  in  Isabelle  is  higher-order 
unification  (i.e.  solving  equations  in  the  typed  A -calculus  with  respect  to  a,  /3  and  rj 
conversion  [24]).  There  is  no  most  general  unifier,  and  so  there  can  be  more  than  one 
higher-order  unifier.  Secondly,  more  than  one  theorem  may  be  able  to  be  resolved  with 
the  goal.  The  tactic  will  fail  if  none  of  the  rules  can  be  unified. 

Another  fundamental  tactic  is  assume_tac  i,  which  tries  to  solve  subgoal  i  by  assump¬ 
tion  (again,  this  may  involve  unification). 

Reasoning  about  definitions  and  deriving  new  rules  is  facilitated  by  a  number  of 
rewriting  tactics.  For  example,  rewrite_goais_tac  thins  uses  the  given  definitional 
theorems  for  rewriting  subgoals.  Excessive  rewriting  is  not  good  Isabelle  style  (and 
can  be  expensive);  the  preferred  strategy  is  immediately  to  derive  elimination  and 
introduction  inference  rules  for  any  new  construct,  and  thereafter  to  use  these  new 
rules  in  resolution  steps. 

Isabelle  also  allows  conditional  object-level  rewriting:  for  example,  simp_tac  ss  i:  uses 
a  given  set  ss  of  object-level  simplification  rules,  and  rewrites  subgoal  i.  Rewriting  can 
be  useful  for  one-off  proofs,  but  is  slow  compared  to  resolution. 

Isabelle  also  has  answer  extraction  available,  via  so-called  scheme  variables.  These 
variables  can  be  part  of  a  goal;  as  tactics  are  applied  the  scheme  variables  may  be 
instantiated  during  the  proof. 

3.7  Tacticals 

The  power  of  a  tactical  theorem  prover  rests  in  the  ability  to  combine  tactics  to  build 
new  ones,  by  means  of  tacticals.  A  selection  of  basic  tacticals  is  as  follows: 


tael  THEN  tac2  (sequencing) 
tael  ORELSE  tac2  (choice) 

REPEAT  tac  (iteration) 

DEPTHFIRST  pred  tac  (search) 

The  tactic  taci  then  tac2,  applied  to  the  proof  state  <f>,  first  computes  taci(^),  giving 
some  list  [ip i,  1P2, ...]  of  proof  states,  and  then  applies  tac2  to  each  of  these  states,  giving 
as  output  the  concatenation  of  the  sequences  tac2 (ipi),  tac2 (tps). 
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The  tactic  taci  orelse  tac2  is  a  form  of  choice:  it  first  computes  taci (<f>).  If  this  is 
non-empty,  it  is  returned  as  the  result;  otherwise,  tac2(0)  is  returned. 

The  tactic  repeat  tac  first  computes  ta c((f>).  If  this  is  non-empty,  then  the  tactics 
recursively  applies  itself  to  each  element,  concatenating  the  results.  Otherwise,  it 
returns  the  singleton  list  [4>]. 

The  tactic  depth_first  pred  tac  performs  a  depth-first  search  for  a  proof-state  satisfying 
pred.  Usually  pred  is  taken  to  be  “no  subgoals”,  so  that  the  tactic  will  search  for  a 
proof  of  the  original  goal. 

4  Operational  Semantics  in  Isabelle 

Isabelle  is  ideal  for  reasoning  about  operational  semantics,  because  it  has  been  designed 
for  natural  deduction,  and  works  well  with  derived  inference  rules.  If  we  regard  our 
operational  semantics  as  the  rules  for  a  logic,  then  we  can  quickly  construct  powerful 
proof  procedures  in  Isabelle  which  allow  reasoning  about  quite  complicated  programs. 

There  will,  in  general,  be  a  number  of  ways  of  capturing  the  operational  semantics 
of  a  given  programming  language  within  Isabelle.  These  are  not  just  matters  of 
implementation  detail,  but  should  be  regarded  as  ‘design’  issues  to  be  resolved  for 
the  logic.  They  are  important,  because  they  influence  the  way  that  the  user  reasons 
about  programs  in  the  language.  In  what  follows,  we  make  some  general  observations 
about  these  issues. 

4.1  Language  Syntax 

The  first  issue  is  how  we  represent  the  syntax  of  the  context-free  language  L  (introduced 
in  Section  2.1)  within  a  new  Isabelle  theory.  First  of  all,  for  each  non-terminal  v  €  V, 
we  declare  a  new  type  Ty(v).  It  is  also  useful  (as  we  shall  see  later)  to  assign  each 
identifier  symbol  in  I  to  the  same  type  Ty(id).  The  type-checking  discipline  imposed 
by  Isabelle  will  carry  out  the  function  of  syntax-checking  for  sentences  in  the  language; 
this  prevents  a  lot  of  errors. 

Now  suppose  that  tt  is  a  production,  of  the  form  v  — >  a,  with 

a  =  r1w1...rnwn 

where  each  is  either  a  non-terminal  or  an  identifier  symbol ,  and  each  w,  is  a  string  of 
other  (non-identifier)  terminal  symbols.  Then  this  production  is  represented  in  the  theory 
by  the  new  constant  C(ir),  with  curried  function  type  [Ty(rj ), Ty(rn)\  =>  Ty(v), 
and  whose  concrete  syntax  is  given  by  the  pattern  of  strings  of  non-identifier  terminal 
symbols  occurring  in  a. 

This  scheme  may  seem  elaborate  (especially  the  treatment  of  identifiers),  but  in  practice 
it  is  very  simple  to  set  up.  An  example  should  help  to  explain  the  technique.  Suppose 
that  plus  is  the  production 


Exp  — >  Exp  +  Exp 
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Then  the  theory  will  contain  a  constant  which  can  be  denoted  by  C(plus),  which  has 
type  [Ty(Exp),  Ty(Exp)]  =*>  Ty(Exp).  The  concrete  syntax  is  given  by  _  +  where  the 
underscores  are  placeholders  for  the  arguments  of  C(plus). 

4.2  Semantic  Domains 

The  second  issue  is  how  we  represent  semantic  objects  within  Isabelle.  As  discussed 
earlier  (in  2.1),  these  are  familiar  set  and  function  theoretic  objects,  well-known  in 
specification  languages  such  as  Z  [25]  and  VDM  [26].  The  decision  we  need  to  make 
is  how  to  reason  about  such  constructs  within  the  context  of  proving  properties  of 
programs  in  the  language  L.  Two  broad  approaches  are  possible,  which  we  shall  now 
describe. 

The  first  approach  is  to  do  what  is  required  from  scratch,  i.e.  forget  about  existing 
Isabelle  logics,  and  represent  all  semantic  objects,  such  as  environments  and  record 
values,  as  new  types’,  provide  a  new  concrete  syntax  for  them,  and  postulate  the 
necessary  introduction  and  elimination  rules  to  allow  the  proof  of  goals  involving  these 
constructs.  The  advantages  of  this  approach  are  that  the  rules  are  natural  and  easy 
to  understand,  and  the  proof  procedures  can  be  reasonably  simple  resolution  tactics. 
However,  the  disadvantages  are  that  a  considerable  number  of  rules  are  required  to 
capture  the  meaning  of  quite  familiar  objects.  Relying  heavily  on  inference  rules  in 
this  way  increases  the  chance  of  errors,  and  could  compromise  the  soundness  of  the 
system.  Moreover,  some  constructs  (such  as  type  closures  in  Standard  ML)  are  difficult 
to  handle  in  a  straightforward  manner. 

The  second  approach  is  to  make  use  of  an  existing  Isabelle  base  logic  which  already 
contains  as  many  of  the  required  set  and  function  theoretical  constructs  as  possible.  Any 
semantic  objects  which  are  not  part  of  the  base  logic  can  be  defined  (using  meta-level 
rewriting)  in  terms  of  simpler  objects,  provided  that  the  logic  is  expressive  enough. 
The  advantages  of  this  approach  are  that  we  do  not  have  to  ‘reinvent  the  wheel’,  and 
design  the  relevant  rules  for  reasoning  about  these  constructs.  We  can  also  make  use  of 
existing  tactics,  in  particular  the  appropriate  simplifier  (rewriting  engine),  if  available. 
This  approach  is  more  likely  to  yield  a  sound  system  than  the  above  because  the  built- 
in  Isabelle  object  logics  are  constructed  using  well-known  axiomatisations.  The  main 
disadvantage  is  that  the  axiomatic  formulation  of  the  logic  may  be  complicated,  and 
take  some  time  and  effort  to  learn  before  proofs  can  be  attempted.  Also,  the  concrete 
syntax  for  the  base  logic  may  clash  with  that  of  the  language  being  studied. 

Our  philosophy  is  to  make  the  correspondence  with  the  formal  definition  of  the  semantics 
of  L  as  close  as  possible,  and  to  rely  on  Isabelle’s  extensive  support  for  reasoning  about 
familiar  semantic  domains.  Therefore,  we  believe  that  the  second  approach  is  preferable. 

Having  decided  on  this  approach,  we  can  distinguish  three  different  kinds  of  rule  in  our 
theory  of  semantic  objects.  These  will  now  be  described. 

4.2.1  Meta-Level  Rewrite  Rules 

Meta-level  rewrite  rules  use  meta-equality  to  define  a  new  construct  A  in  terms  of  other 
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constructs.  Such  rules  take  the  form 

When  A(ti,...,tn)  occurs  in  a  formula,  it  can  be  expanded  according  to  its  definition 
by  applying  meta-level  rewriting  (sometimes  called  unfolding  —  the  reverse  operation 
is  called  folding).  It  is  possible  for  the  right  hand  side  of  the  rule  to  involve  A,  so  that 
recursive  definitions  can  be  made.  This  must  be  done  with  care,  in  order  to  ensure  that 
no  inconsistencies  are  introduced  into  the  logic. 

An  example  of  this  is  the  definition  of  variable  environments  for  elaboration  (see  Section 
1°): 

VarEnv  ==  ( SUM  x  :  {  Far,  Con,  ExCon}.x)  — > TypeScheme 

which  expresses  the  fact  that  a  variable  environment  is  a  finite  map  from  the  disjoint 
union  of  the  classes  of  variables,  value  constructors  and  exception  constructors  to  the 
set  of  typeschemes. 

4.2.2  Introduction/Elimination  Rules 

These  have  been  mentioned  earlier  (see  Section  2).  Rules  of  the  form: 

\Ai ;  •••;  An ]  =£•  A 

can  be  regarded  as  introduction  rules  for  A,  or  as  an  elimination  rule  for  one  of  the 
assumptions  Aj.  They  may  be  derived  from  definitions  (see  above),  or  even  postulated 
directly.  An  example  of  such  a  rule  is 

\f  :  A^B-  g  :A^B]^f]g  :  A  ->  B 

which  says  that  if  /  and  g  are  functions,  then  /  overwritten  by  g  is  also  a  function 
(see  5.1) 

4.2.3  Object-Level  Rewrite  Rules 

Object-level  rewriting  can  be  used  to  transform  terms  with  respect  to  some  relation  > 
which  is  both  reflexive  and  transitive.  Most  commonly,  the  appropriate  relation  is  either 
logical  equivalence  or  equality  in  First  Order  Logic  and  its  extensions. 

Rules  of  the  form 

[A/,...,  A„]  =►  P  >  P' 

can  be  used  for  (conditional)  rewriting,  making  use  of  the  simplifier.  The  intention  is 
that  any  subterms  P  of  a  given  term  can  be  rewritten  at  the  object-level  to  P',  provided 
the  pre-conditions  A/ , ...,  An  are  met.  For  example,  in  our  theory  we  have  the  rules 

/  f  0  =  f  (for  functions) 

A  Un  0  =  A  (for  sets) 

These  can  be  used  as  object-level  rewrite  rules,  and  taken  account  of  by  the  simplifier, 
if  required.  Often,  a  special  tactic  will  be  needed  for  solving  the  subgoals  arising  from 
conditional  rewrites. 

Note  that  the  new  Isabelle  simplifier  is  less  general  than  described  here,  but  considerably 
faster.  It  is  still  sufficiently  general  to  cover  all  our  uses  in  the  Elle  system. 
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4.3  Language  Semantics 

Finally,  we  need  to  represent  the  semantics  of  the  language  L  itself  within  Isabelle. 
Language  sequents  of  the  form  C  o  =>  C  will  be  represented  by  formulae. 

To  represent  the  language  inference  rules  in  Isabelle,  we  recall  the  need  to  capture 
meta-level  reasoning.  We  express  the  inference  rules  in  ZF  in  the  following  form: 

3x  €  Condsi\C  b„  a  =>■  C' .Condf  A  ...  A  Condf‘^J\/ 

^3#  £  Condsn\C  h,  a  =$■  C'.Cond f  A  ...  A  Condf'1 
&C\~V  a  =*•  C' 

where  3x  £  Condsi\C  \-v  a  =>  C1  denotes  existential  quantification  over  all  the  semantic 
variables  present  in  Condf , ...,  Condf  but  not  in  the  conclusion  C  a  =$■  C'  of  the  rule. 

Of  course,  from  the  above  inference  rules  we  can  derive  both  introduction  and  elim¬ 
ination  rules  for  C  \~v  a  =$■  C'.  We  can  automate  this  process,  by  means  of  the  ML 
functions: 

mk_intr_rule  :  thm  ->  thm  list 

get_intr_rules  :  theory  ->  string  *  string  list  list  ->  thm  list 
mk_elim_rule  :  thm  ->  thm 

The  function  mk_intr_ruie  produces  the  introduction  rules: 

Condf  ...  Condf1 
C  \~v  ot  =$>  C' 

Condf  ...  Condf1 
C  hv  a  =>  C1 

The  function  get_intr_ruies  is  somewhat  similar,  but  takes  an  extra  argument  which, 
for  each  of  these  resulting  rules,  allows  one  or  more  equality  substitutions  to  be  made 
where  the  premises  permit.  The  function  mk_eiim_ruie  :  thm  ->  thm  is  used  to  derive 
elimination  rules;  these  will  not  be  discussed  in  this  paper. 

5  Set-Theoretic  Reasoning  in  Isabelle 

We  have  chosen  to  build  our  new  logics  on  top  of  Isabelle’s  Zermelo-Fraenkel  Set 
Theory  (ZF),  which  is  an  extension  of  First-Order  Logic  (FOL).  This  theory,  being 
concerned  with  establishing  the  familiar  properties  of  sets  and  functions  from  primitive 
axioms,  is  a  natural  choice.  An  alternative  would  have  been  to  use  Isabelle’s  Higher- 
Order  Logic  (HOL).  We  chose  ZF  because  it  is  simpler  than  HOL.  Its  type  system  is 
weaker  than  that  of  HOL  (everything  in  ZF  is  a  set  —  and  can  have  only  one  type), 
but  this  can  be  an  advantage  when  we  wish  to  overload  notation  for  semantic  objects 
without  getting  distracted  from  the  constructs  of  real  concern  —  syntax  and  semantics 
of  the  language. 


15 


DSTO-RR-0008 


Isabelle’s  ZF  [6]  is  the  work  of  Martin  Coen,  Philippe  Noel  and  Lawrence  Paulson, 
and  is  now  a  highly  developed  theory,  with  an  enormous  number  of  derived  rules,  and 
a  sophisticated  simplifier.  Further  work  by  Paulson  has  demonstrated  the  usefulness 
of  ZF  as  a  computational  logic,  i.e.  it  provides  simple  but  sufficient  machinery  for 
reasoning  about  recursive  functions  and  datatypes  [19].  The  reader  should  consult  these 
references  for  more  details  of  the  Isabelle  implementation  of  ZF. 

Most  of  the  notation  we  shall  use  is  fairly  standard.  We  note  that  elements  of  the 
disjoint  union 


At  U  ...  U  An 


are  pairs  of  the  form 


( Ai,Xi )  where  Xi  G  A{  ( 1  <  i  <  n) 

Thus  we  can  identify  which  of  the  sets  Ai  the  elements  belongs  to  by  using  the  name 
of  Ai  itself  as  a  label.  (This  works  provided  the  A,  are  all  mutually  distinct). 

For  our  work,  it  was  necessary  to  derive  a  number  of  extensions  of  Isabelle’s  ZF  in  order 
to  allow  reasoning  about  semantic  objects.  We  shall  now  describe  these  extensions. 

5.1  Funtion  Overwriting 

An  important  operation  in  the  semantics  of  a  language  such  as  SML  is  that  of  overwriting 
one  function  with  another.  Many  of  the  language  inference  rules  involve  overwritten 
variable  environments.  There  are  a  number  of  ways  of  defining  this  operation;  we  adopt 
the  following,  as  being  the  most  useful  for  subsequent  development.  If  /  and  g  are 
functions,  then  we  define 

/  f  9  ={P  ^  /  |  -'fst(p)  G  domain(g)}  U  g 

(This  definition  also  makes  sense  if  /  is  a  relation).  Thus  the  bindings  in  /  are 
overwritten  by  those  in  g,  for  example 

{( x,l),(y,2),{z,3 )}  f  {(x,2),(w,5)}  = 
{(x,2),(y,2),(z,3),(w,5)} 

Various  kinds  of  semantic  goals  involving  functions  are  possible.  The  most  common 
are: 


(/  t  s)  {*) 

/  (x)  =?o 

in  which  each  right-hand  side  is  yet  to  be  instantiated,  and  where  /  and  g  are  concrete 
functions.  We  need  an  efficient  technique  for  dealing  with  these  goals  in  such  a  way 
that,  at  the  end  of  a  proof,  all  terms  involving  function  overwrites  and  applications  will 
be  fully  evaluated. 
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To  achieve  this,  we  derive  a  number  of  rules  about  overwrite.  First  of  all,  we  have 
the  introduction  rules: 

<*'°>eg  (tin 

{*,  a)  €  /  ->x  E  domain(g) 

(x,  a)  £  f  ]  g  (T  j 


Overwrites  can  be  computed  directly  via 

_ (a,  b)  £  g _ 

cons((x,a),f)  \g  =f  \g 

->x  £  domain(g) 


(cons  f  II) 


cons((x,  a),f)  f  g  =  cons((x ,  a)J  \  g) 


(cons  f  12) 


A  number  of  other  useful  rules  have  been  derived,  including: 


/  €  A  ->  B  g£C  -»  D 
f  t  g  €  domain(f  f  g) -*  range(f  f  g) 


(t  -  type) 


/  t  (9  t  h)  =  (/  t  g)  t  h  (t  -  assoc) 

0f/ =/  (|0 -left) 

/t  0  =/  (f0- right) 

domain(f  t  g)  =  domain(f)  U  domain(g)  (domainf) 

These  rules  are  immediately  suitable  for  use  in  object-level  rewriting,  and  semantic 
goals  can  indeed  be  attacked  in  this  way.  However,  the  Isabelle  simplifiers  are  not  as 
efficient  as  one  would  like,  and,  after  much  experimentation,  we  discovered  that  it  was 
consistently  more  efficient  in  the  Elle  system  to  use  versions  of  these  rules  suitable 
for  resolution.  These  rules  have  the  suffix  “-equality”,  and  are  trivial  to  derive.  An 
example  is 


(Mj /  U  =  h 

cons((x,  a),f)  f  g  =  h 


(cons  f  II  —  equality) 


The  conclusion  of  this  rule  will  now  match  any  subgoal  of  the  form 


f'U^h 

in  which  f  is  of  the  form  cons((x,  o),/)  or  is  a  scheme  variable. 
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5.2  Handling  Distinct  Variables 

To  compute,  say. 


{{*,«)}  t  {{y, &)}  =  {(x,g),(i/,  6)} 

it  is  tacitly  assumed  that  x  and  y  are  distinct  variables.  However,  Isabelle  has  no  way  of 
knowing  this,  and,  use  of  the  overwrite  rules  will  yield  a  subgoal  asserting  that  ~>x  =  y. 
To  avoid  the  problem  of  making  tiresome  and  lengthy  assertions  of  inequalities,  we  use 
a  scheme  designed  to  provide  a  set  of  “reserved”  variable  names  which  are  guaranteed 
to  be  mutually  distinct.  This  is  done  by  ‘tagging’  names  with  a  unique  binary  number. 
This  is  implemented  in  the  theory  Tags,  which  is  described  in  the  Appendix. 

6  The  Definition  of  Standard  ML 

Readable  introductions  to  Standard  ML  (SML)  can  be  found  in  the  books  by  Paulson  [27] 
and  Wikstrom  [28].  Here  we  shall  just  highlight  the  main  features  of  the  language: 

•  It  is  a  functional  language  —  functions  are  first-class  objects  and  can  be  passed 
as  arguments  to  other  functions,  or  returned  as  values. 

•  It  is  statically-scoped:  identifiers  are  associated  with  values  according  to  where 
they  appear  in  the  program  text  (and  not  on  the  run-time  behaviour  of  the 
program). 

•  It  is  a  strongly  typed  language:  every  ML  expression  has  a  statically- 
determined  type. 

•  It  is  polymorphic  —  type  expressions  may  contain  type  variables,  allowing 
for  functions  to  be  defined  on  a  class  of  arguments  of  different  types. 

•  It  has  facilities  for  abstraction  —  the  user  can  define  new  abstract  data  types 
and  hide  the  details  of  their  implementation  from  functions  which  make  use 
of  them. 

•  It  has  a  modules  facility,  allowing  the  grouping  of  large  ML  programs  into 
separate  units  which  can  be  separately  compiled. 

•  It  has  an  exception  trap  mechanism,  to  allow  the  uniform  handling  of  user 
and  system-generated  exceptions. 

•  It  has  a  formal  semantics  —  the  language  definition  of  SML  [1]  is  expressed 
in  terms  of  operational  semantics 

The  formal  semantics  of  Standard  ML  has  been  given  by  Milner,  Harper  and  Tofte  [1], 
(referred  to  in  what  follows  as  ‘the  Definition’).  The  companion  Commentary  [29] 
gives  some  insight  into  the  Definition. 

The  Definition  presents  the  syntax  for  SML  (both  for  the  Core  language  and  the  Modules 
System),  introducing  various  identifier  and  phrase  classes. 

The  static  semantics  (i.e.  type-checking,  or  elaboration  of  phrases)  involves  a  rich  set  of 
simple  and  compound  semantic  objects  (such  as  environments,  types  etc).  Elaboration 
of  a  phrase  is  expressed  by  a  sequent  of  the  form 

C  h  phrase  =>  result 
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where  typically  C  is  a  context,  and  the  result  may  be  a  type  or  a  type  environment. 
The  102  inference  rules  capture  all  the  possible  inferences  among  these  sequents. 

The  dynamic  semantics  (evaluation  of  phrases)  is  given  a  similar,  but  separate,  treatment. 
The  fact  that  evaluation  and  elaboration  can  be  dealt  with  independently  is  an  important 
aspect  of  SML.  Often  the  same  terminology  gets  used  in  both  the  static  and  dynamic 
semantics  but  has  a  different  meaning  in  each  case,  such  as  “variable  environment”. 
Static  and  dynamic  semantics  meet  at  the  level  of  programs,  where  the  evaluation  of  a 
program  is  only  carried  out  if  it  elaborates  successfully. 

Standard  ML  has  a  number  of  phrase  classes  which  are  derived  forms.  For  example, 
the  program  phrase  case  exp  of  match  is  defined  to  be  the  more  primitive  language 
expression  (fn  match)(exp).  Other  examples  of  derived  forms  are  if,  andalso  and 
orelse  as  well  as  lists  and  tuples.  Inference  rules  only  need  to  be  given  for  the  phrases 
in  the  so-called  ‘bare’  language. 

Because  of  their  formal  nature,  and  the  size  of  the  language,  the  Definition  and 
Commentary  are  not  light  reading,  and  are  aimed  at  implementers  and  ML  experts 
more  than  the  general  reader.  The  Definition  allows  one  in  principle  to  explore  language 
semantics,  but  detailed  proofs  done  on  paper  using  all  the  196  inference  rules  are  far 
too  laborious:  we  believe  that  machine  support  is  essential  to  be  able  to  do  this. 

In  the  following  Sections,  we  shall  describe  our  approach  to  reasoning  about  SML 
within  the  Isabelle  prover. 


7  Overview  of  The  Elle  System 

At  present,  we  have  built  a  system  which  captures  the  syntax  and  semantics  of  a 
substantial  subset  of  Standard  ML,  namely  the  pure  functional  (side-effect  free)  subset 
of  the  Core  Language.  This  subset  will  be  denoted  by  T.  The  subset  includes  pattern 
matching,  functions  as  first-class  objects  and  recursion.  We  have  excluded  imperative 
features  such  as  reference  variables,  assignments,  and  exceptions,  as  well  as  the  modules 
system.  However,  what  remains  is  still  an  extremely  rich  language. 

In  the  spirit  of  the  Definition  [1],  elaboration  (static  semantics)  and  evaluation  (dynamic 
semantics)  are  treated  separately;  this  is  reflected  in  the  design  of  the  system.  Thus, 
separate  Isabelle  theories  are  maintained:  one  for  elaboration  and  one  for  evaluation. 
They  have  in  common  the  syntax  of  T  itself. 

The  syntax,  semantic  objects  and  inference  rules  of  T  are  captured  in  a  series  of  new 
(typed)  Isabelle  object  logics,  or  theories,  built  on  top  of  ZF.  The  various  semantic 
objects,  such  as  values  and  environments  are  themselves  given  an  appropriate  concrete 
syntax,  and  their  properties  described  by  means  of  inference  rules  within  the  logic  C 
for  the  various  operations  defined  on  these  domains. 

In  this  section,  we  shall  describe  the  structure  of  the  Elle  system.  The  theory  hierarchy 
of  the  system  is  shown  in  Figure  1. 
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Kernel 


EvalObj 

ElabObj 

EvalAtExp 

ElabAtExp 

EvalExpRow 

ElabExpRow 

EvalExp 

ElabExp 

EvalMatch 

ElabMatch 

EvalMrule 

ElabMrule 

EvalDec 

ElabDec 

EvalValBind 

ElabValBind 

ElabTypBind 

ElabDatBind 

ElabConBind 

ElabExBind 

EvalAtPat 

ElabAtPat 

EvalPatRow 

ElabPatRow 

EvalPat 

ElabPat 

ElabTy 

ElabTyRow 

ElabTySeq 

EvalProgram 

ElabProgram 

Figure  1  Structure  of  the  Elle  System 


8  The  Kernel 

The  Kernel  of  the  system  is  an  ML  image  which  consists  of  all  the  Isabelle  machinery 
(theories,  derived  rules  etc)  which  is  common  to  both  elaboration  and  evaluation.  It 
includes  the  extensions  overwrite  and  Tags  of  ZF  set  theory  which  were  described 
earlier  in  Section  5,  as  well  as  the  Isabelle  theories  identifiers  and  SML_syntax  which 
describe  the  syntax  of  the  language  T. 

The  theory  hierarchy  is  shown  in  the  Figure  2  (the  existing  ZF  theories  are  shown  boxed 
and  the  new  theories  defined  for  the  Elle  system  are  shown  unboxed). 


20 


DSTO-RR-0008 


Kernel 


Figure  2  Kernel  Theory  Hierarchy 


8.1  The  Theory  Identifiers 

The  theory  identifiers  is  an  extension  of  Tags,  and  defines  the  various  classes  of 
identifiers  used  in  SML,  as  well  as  defining  a  number  of  built-ins  and  reserved  names 
for  each  of  these  classes  —  all  guaranteed  to  be  distinct  by  virtue  of  the  machinery 
established  in  Tags. 

Table  6  shows  the  various  classes  of  identifiers  (each  is  a  set),  and  lists  the  associated 
built-ins  and  reserved  names.  For  example,  plus  is  a  built-in  function,  whose  meaning 
for  evaluation  is  recorded  in  the  initial  (dynamic)  environment  in  terms  of  the  semantic 
apply  function  [1],  and  whose  type  is  recorded  in  the  initial  static  environment.  The 
variables  xi,...,  xg  are  guaranteed  via  the  Tags  mechanism  to  be  distinct,  and  can  be 
used  for  general-purpose  value  variables;  we  also  have  which  can  be  used 

for  user-defined  ML  functions.  The  variable  it  is  special:  it  is  used  to  record  the 
value  of  the  most  recently  entered  expression.  The  record  labels  ni  and  ns  are  special 
ones  which  denote  the  components  of  an  ordered  pair,  while  pi,...,pe  can  be  used  for 
general  record  labels. 
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Table  6  Identifiers  Used  in  the  Kernel 


Name 

of 

Class 

Description 

Built-Ins 

Reserved  Names 

Var 

value 

variables 

plus ,  minus ,  times ,  less 
zero ,  not , 
head ,  tail ,  null 

*  ^ 

-4  a 

Con 

value 

constructors 

true,  false,  nil,  CONS 

Ci ,  ...,  Cg 

ExCon 

exception 

constructors 

ERROR,  MATCH,  BIND 

TyVar 

type  variables 

® 1 1  •••)  0-9 

TyCon 

type 

constructors 

/AT,  BOOL ,  UNIT,  EXN ,  List 

Ti,...,  Tg 

Lab 

record  labels 

nun2 

Pl>-iP 6 

Strld 

structure 

identifiers 

Si ,  ...,  Sg 

8.2  The  Theory  SML_Syntax 

Our  aim  has  been  to  use  wherever  possible  the  syntax  of  SML.  Table  7  gives  the  concrete 
syntax  for  the  bare  (i.e.  nonderived)  part  of  JF,  the  subset  of  SML  which  is  supported 
by  the  Elle  system.  We  adopt  the  conventions  of  the  Definition  [1]:  in  particular,  we 
have  used  the  angled  brackets  ‘<  >’  to  enclose  optional  phrases. 
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Table  7  Syntax  of  Bare  Part  of  T 

exp  ::  = 

scon  n  pat :: 

= 

var  x 

scon  n 

con  c 

var  x 

excon  e 

con  c 

{{  <exprow>  }} 

excon  e 

let  dec  in  exp  end 

{{  <patrow>  }} 

( -  exp  - ) 

( -  exp  - ) 

expi  '  exp2 

con  con  c  pat 

expi  id  exp2 

excon  e pat 

exp  :  ty 

pat i  con  c  pat2 

exp  handle  match 

pati  excon  e  pat 2 

raise  exp 

var  x  <:  ty>  as  pat 

fn  match 

pat  :  ty 

exp  row  ::  = 

lab  =  exp  <  ,exprow> 

patrow  ::  = 

match  ::  = 

pat  =>  exp  <  1  match> 

pat  =  exp  <  ,patrow> 

dec  ::  = 

val  valbind 

ty  ::  =  tyvar 

type  typbind 

{{  <tyrow>] } 

datatype  datbind 

tyseq  tycon 

abstype  datbind  with  dec  end 

ty  -ty->  ty’ 

exception  exbind 

(-  ty  -) 

local deci  in  dec2  end 

decj  <;>  dec 2 

tyrow  ::  =  lab  :  ty  <  ,tyrow> 

valbind 

pat  =  exp  <and  valbind> 

rec  valbind 

typbind 

tyvarseq  tycon  =  ty  <and 
typbind> 

datbind 

tyvarseq  tycon  is  conbind  <and 
datbind> 

conbind 

con  c  <of  ty>  <  \  conbind> 

exbind 

excon  e  <of  ty>  <and  exbind> 

excon  el  =  excon  e2  <and 
exbind> 
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For  example,  the  factorial  function  is  given  by 

val  rec  var  fl  =  fn  var  xl  => 

(-  if  zero  var  xl  then  scon  succ  (0)  else 

(-  var  xl  **  (-  var  fl  '  (-  var  xl  —  scon  succ  (0)  -)-)-)-) 

Some  of  the  relevant  productions  are 

exp  —v  fn  match 

match  — >  pat  =>  exp  (  |  match ) 

which  are  easily  expressed  as  the  following  Isabelle  syntax  declarations: 

Fn  ::  "Match  =>  Exp"  (“  (lfn  _)  11  ) 

Mrule  ::  "[  Pat,  Exp]  =>  Match"  ( " (_  =>/  _) “ ) 

Match_  ::  11  [  Pat,  Exp,  Match]  =>  Match"  ( "  (_  =>/  _  |/  _)") 

Note  that  Match  and  Exp  appear  as  new  types  in  the  logic;  thus  Isabelle’s  type-checking 

will  catch  syntax  errors. 

The  definition  of  the  syntax  is  taken  almost  verbatim  from  the  Definition,  with  the 

following  important  differences. 

•  A  number  of  constructs  need  some  extra  concrete  syntax  as  “dressing”  to 
enable  Isabelle  to  disambiguate  them  from  other  constructs.  This  can  be 
seen  in  the  factorial  example  above,  in  which  the  variables  are  marked  with 
the  word  var.  Other  examples  are  special  constants,  value  constructors  and 
exception  constructors,  as  well  as  the  analogous  patterns  and  constructor 
bindings. 

•  The  phrase  classes  of  atomic  expressions  ( AtExp )  and  expressions  (Exp)  are 
not  distinguished,  and  have  been  collapsed  here  into  the  single  class  Exp.  The 
same  applies  to  atomic  patterns  (AtPat)  and  patterns  (Pat).  Also  the  phrase 
class  Mrule  is  not  used. 

•  Isabelle  allows  some  limited  overloading  —  for  example,  record  expres¬ 
sions  and  patterns  are  both  denoted  by  the  same  double  brackets,  such  as 
{{pi  =  var  xi,  p2  =  var  x2}>.  Unfortunately,  use  of  single  brackets  would 
lead  to  confusion  with  ZF  sets! 

•  Brackets  in  the  language  are  denoted  by  <-  ...  to  avoid  confusion  with 
Isabelle’s  meta-level  brackets  (...) 

•  Function  application  is  denoted  by  a  backquote,  such  as  var  fi  *  var  xi. 
Simple  juxtaposition,  as  in  var  fi  var  xi,  gets  confused  with  Isabelle’s  meta¬ 
application. 

•  For  type  bindings,  the  syntax  is  tyvarseq  tycon  is  ty,  and  not 
tyvarseq  tycon  =  ty  ,  which  causes  Isabelle  problems  in  parsing 

•  Function  types  are  denoted  by  a  -ty->  b 

•  Open  declarations,  fixity  directives  and  ‘op’  qualifiers  have  been  ignored. 

In  addition  to  the  above  bare  constructs,  SML  has  a  large  number  of  derived  forms. 

Table  8  shows  the  derived  forms  supported  by  the  Elle  system. 
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Table  8  Syntax  of  Derived  Forms  of  T 


(-  exp i,  exp 2~) 

pat  ::= 

(-  pat i,pat2- 

expi  +  exp  2 

ty  ::= 

ty,  <*>ty2 

expi  -  exp  2 

Int 

expi  *  exp2 

Bool 

exp  i  <  exp2 

Exn 

expi  orelse  exp2 

tyseq  ::= 

<> 

expi  andalso  exp 2 

<tyargs> 

if  expi  then  exp2  else  exp 3 

program  ::= 

exp  ; 

case  exp  of  match 

expseq  ::= 

exp 

zero  exp 

exp  ,  expseq 

not  exp 

tyargs  ::= 

ty 

head  exp 

ty  ,  tyargs 

tail  exp 
null  exp 
[] 

[expseq] 
exp  i  : :  exp2 


9  Evaluation  (Dynamic  Semantics) 

In  this  section  we  shall  describe  how  the  dynamic  semantics  of  the  language  T  is 
captured  within  Isabelle.  We  shall  follow  the  treatment  given  in  Chapter  6  of  the 
Definition  [1].  This  reference  should  be  consulted  for  more  detailed  explanations  of 
the  terms  used. 

9.1  The  Theory  EvalObj 

The  semantic  objects  for  evaluation  are  all  defined  within  the  theory  Evaiobj ,  which 
is  an  extension  of  Kernel. 

The  simple  semantic  objects  are  as  follows: 


Addr 

addresses 

ExName 

exception  names 

BasVal 

basic  values 

SVal 

special  values 

FAIL 

failure  element 
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Addr  and  ExName.  are  infinite  sets.  BasVal  denotes  the  set  of  values  bound  to  pre¬ 
defined  variables,  i.e.  BasVal  =  {plus,  minus,  times,  less ,  zero,  not,  head,  tail,  null}. 
SVaf  is  the  set  of  values  denoted  by  the  special  constants  SCon.  FAIL  is  used  in  the 
semantics  simply  to  record  the  failure  of  a  pattern  to  match  a  value.  All  these  sets  are 
declared  in  Evaiobj. 

The  compound  semantic  objects  ([1],  p47)  are  defined  as  follows 


Val  =  SVal  U  BasVal  L)  Con  U  ConValU 

ExVal  U  Record  U  Addr  U  Closure 
Record  ee  Lab  Val 
ExVal  =  ExName  U  ( ExName  x  Val ) 

Back  —  { Raised]  x  ExVal 
Conval  =  Con  x  Val 

Mem  =  Addr  ^  Val 
ExNameSet  =  Fin(ExNamc) 

State  =  Mem  x  ExNameSet 

Env  =  StrEnv  x  VarEnv  x  ExConEnv 

StrEnv  =  St  rid  Env 

VarEnv  =  ( Var  U  Con  U  ExCon )  Val 

ExConEnv  =  ExCon  —>  ExName 


On  comparison,  it  should  be  clear  how  the  use  of  ZF  has  allowed  us  to  follow  the 
Definition  extremely  closely  (note,  however,  that  we  have  omitted  the  :  =  operator  from 
Val). 

Environments  (i.e.  members  of  Env )  are  combined  by 


(SE,  VE,  EE)  f  (SE',  VE',  EE')  =  (SE  f  SE' ,  VE  |  VE’,  EE  \  EE') 


where  the  angle  brackets  are  standard  ZF  notation  for  tuples. 
The  initial  environment  is  given  by  the  rules 
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where 


sE0  =  m 

VEq  =  {((Var,  plus)  (BasVal,  plus)), 

((  Var ,  minus)  (BasVal,  minus)), 
((  Var ,  times),  ( BasVal ,  tim.es)), 
((  Var,  /ess),  ( BasVal ,  less)), 

((  Var,  zero),  { BasVal ,  zero)), 

((  Var,  no/),  { BasVal ,  not)), 

{(  Var,  head),  ( BasVal ,  head)), 

((  Var,  Za*7),  { BasVal ,  tail)), 
((Var,  null),  ( BasVal ,  null)), 
((Con,  true),  (Con,  true)), 
((Con,  false),  (Con,  false)), 
((Con,  nil),  (Con,  nil)), 

((Con,  CONS),  (Con,  CONS))) 

EE0  =  0 


The  meaning  of  built-ins  such  as  plus  is  given  by  the  semantic  apply  function.  For 
example,  the  rule  for  the  built-in  p/ws  is  most  usefully  expressed  as  folllows 


(3&.m  +  n  =  &  &  (SVal,  k)  —  v) 
apply  ((BasVal,  plus). (m,n))  —  v 


where  the  value  (m,  n)  is  a  kind  of  derived  form,  and  is  a  shorthand  for 

((Record,  (nj,SVal,  m),  (ns,  SVal,  n))) 

The  rules  for  the  other  built-ins  are  rather  lengthy,  and  will  not  be  given  here. 

The  dynamic  semantics  needs  to  have  function  closures:  in  order  to  achieve  cor¬ 
rect  call-time  environments,  the  apply  function  is  extended  to  closures.  When  we 
apply  closure(match,  E,  VE)  to  the  value  v,  match  is  evaluated  against  v,  in  the  en¬ 
vironment  E  modifed  by  Rec  VE.  For  details  of  these  technical  issues,  we  refer  to 
the  Definition  (p.49);  it  suffices  to  say  here  that  they  are  handled  correctly  by  the  Elle 
system. 

Reasoning  about  semantic  objects  can  be  carried  out  by  the  following  tactics: 

obj_step_tac  :  int  ->  tactic 
apply_tac  :  int  ->  tactic 

obj_tac  :  int  ->  tactic 

Essentially,  obj_step_tac  carries  out  a  single  resolution  step  using  appropriate  intro¬ 
duction  rules  derived  from  Evaiobj .  The  tactic  apPiY_tac  takes  care  of  goals  involving 
the  built-in  functions  plus,  minus  etc.  Finally,  obj_tac  uses  depth-first  search  to  solve 
a  particular  subgoal. 

val  obj_tac  =  DEPTH_S0LVE_1  o  obj_step_tac; 
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9.2  The  Theories  EvalAtExp,  Eval  Program 

9.2. 1  Inference  Rules 

For  the  most  part,  the  inference  rules  capturing  the  dynamic  semantics  of  T  are  easily 
expressed  in  Isabelle. 

The  theories  EvalAtExp,  ...  ,  EvaiProgram  form  a  linear  chain  extending  Evaiobj.  Below, 
we  give  the  detailed  rules  for  the  theory  EvalAtExp  (these  correspond  to  rules  103  to 
109  in  the  Definition). 


(  Val,  SVal.  n)  =  v' 


E  h  scon  n 


T  (Sconft) 


(3SE  VE  EE.E  =  ( SE ,  VE,  EE)  A  VE((Var,  x))  =  vA(  Val ,  v)  =  v') 


E  b  var  x  =>  v' 

(  Val,  Con,  c)  —  v1 


(Var  ft) 


(Con  ft) 


E  b  con  c  =>  v' 

(3SE  VE  EE.E  =  (SE,  VE,  EE)  A  EE((ExCon,  e ))  =  en  A 
(Val,  ExVal,  Ex  A' amc.cn)  =  v) 

- — - : — -  (ExCon 

L  r  excon  e  =$•  v 

(Val Record.  0)  =  v' 

—7 77  i  \~r~7 —  (Empty Record  ft) 


(3vccord.E  b  exprow  =$■  (  Val,  record)  A  ( Val,  Record,  record)  —  vr) 
E  E  {  {  exp  row  }  }  =>  v' 

(3E1  E".E  h  dec  =»  E’  A  E\E’  =  E"  A  E"  F  exp  =»  v' 

E  h  let  dec  in  exp  end  =>  v' 

E  b  exp  =>  v1 


(Record  ft) 
(Let  ft) 


E  b  (  —  e  xp  —  )  =y  v 


j  (Bracket  ft) 


The  following  rule  is  important: 

(3  VE.E  b  val  bind  ^  VE  A  (0,  VE,  0)  =  E’) 

E  b  val  valbind  =»  E'  (  «  ft) 

These  rules  are  all  two-way  (symmetric)  rules  involving  logical  equivalence  between 
the  conclusion  and  the  conjunction  of  the  premises:  for  convenience,  such  rules  are 
identified  by  the  symbol  ft  in  their  name. 

9.2.2  Introduction  Rules 


The  first  stage  is  to  derive  the  necessary  introduction  rules  for  sequents  involving  all 
the  possible  kinds  of  language  phrase.  (We  refer  to  the  general  discussion  in  Section  4). 
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As  a  first  example,  consider  the  rule  Scon  The  naive  introduction  rule  would  be 

(Val,  SVal,  n)  =  v' 

-L—, - - - -  (Scon!) 

E  b  scon  n  =>  v' 

However,  it  is  more  useful  to  make  the  equality  substitution  for  v',  and  use  the  rule 
in  the  form 


E  b  scon  n  =$>  (  Val ,  SVal,  n)  (Seoul) 

As  a  second  (contrasting)  example,  consider  the  rule  Let  In  this  case,  the  obvious 
introduction  rule 


E  b  dec  =»  E';  E  f  E'  =  E"  E”  b  exp  =>  v' 
E  b  let  dec  in  exp  end  =$>■  v' 


(Letl) 


is  the  one  which  must  be  used.  We  might  be  tempted  to  make  the  equality  substitution 
for  E",  giving 

E  \~  dec  =$■  E'  E  f  E'  b  exp  v' 

- j - - - : -  (ijGtl) 

E  r  let  dec  in  exp  end  =>  v 


However,  this  form  of  the  rule  would  make  it  difficult  to  establish  the  value  of  E  f  E' 
(with  E  known,  and  E'  unknown),  and  thus  the  Isabelle  proof  would  falter. 

In  general,  we  make  equality  substitutions  in  deriving  introduction  rules  only  when  the 
term  appearing  after  the  substitution  is  made  does  not  need  to  be  subjected  to  further 
reasoning  to  obtain  its  value. 

The  appropriate  introduction  rule  for  Val  is 


E  b  valbind  =>•  VE 
E  b  val  valbind  =$  (0,  VE ,  0) 


(Val  I) 


We  use  the  ML  variable  intr_ruies  to  denote  the  list  of  all  introduction  rules  for  the 
evaluation  of  language  sequents.  These  are  supplemented  by  the  special  rules 


((Far,  x),v)  £  VEo 
Eo  b  var  x  =>  v 


(Var_init) 


((Var,  plus)  ,Bas  Val,  plus)  £  VEq  (VE0_mems) 


((Con,  CONS),  Con,  CONS)  £  VE0 


which  hide  some  of  the  tedious  reasoning  about  built-ins. 
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9.3  Proof  Procedures 

The  aim  of  the  Isabelle  proof  procedures  for  evaluation  is  to  support  reasoning  which 
enables  one  to  establish  the  truth  of  sequents  of  the  form 

E  b  phrase  =y  result 

in  which  E  is  a  (fixed)  environment,  and  the  language  phrase  is  typically  an  expression, 
declaration  or  program.  The  result  of  the  evaluation  may  or  may  not  be  known  —  if 
not,  it  is  modelled  by  an  Isabelle  scheme  variable  to  be  instantiated  during  the  proof. 

The  proof  procedures  are  simple  Isabelle  tactics  which  capture  the  way  one  would 
construct  a  proof  tree  [29],  Starting  from  the  initial  goal  (the  root  of  the  tree),  we 
keep  resolving  with  the  appropriate  inference  rules,  simplifying  environments  as  we 
go,  until  all  language  phrases  have  disappeared.  We  then  simplify  using  the  inference 
rules  for  semantic  objects  until  we  reach  the  leaves  of  the  tree.  Isabelle  keeps  track 
of  the  instantiations  made  as  we  go.  Evaluations  which  involve  pattern  matching  may 
require  backtracking  search.  To  accommodate  this,  our  proof  procedures  use  the  Isabelle 
depth-first  search  strategy. 

The  basic  Isabelle  step  tactics  for  evaluation  are: 

eval_step_tac  :  int  ->  tactic 
step_tac  :  int  ->  tactic 

The  aim  of  evai_step_tac  is  to  apply  one  of  the  introduction  rules  for  sequents,  in  a 
controlled  fashion.  The  sequent  E  h  phrase  =>  result  is  called  indeterminate  if  phrase 
is  a  scheme  variable.  Clearly,  in  the  usual  case  where  result  is  a  scheme  variable,  an 
indeterminate  sequent  can  be  resolved  with  any  introduction  rule,  leading  to  erroneous 
paths  in  the  proof  tree;  we  wish  to  avoid  this  by  making  evai_step_tac  check  that  the 
subgoal  does  not  contain  an  indeterminate  sequent,  and  fail  if  it  does.  To  do  this,  we 
use  the  function 

SUBGOAL  :  (term  *  int  ->  tactic)  ->  int  ->  tactic 

which  allows  a  tactic  to  inspect  a  particular  subgoal,  and  take  appropriate  action. 

The  all-purpose  step_tac  tries  in  turn  to  reduces  a  sequent,  if  possible;  to  use  the 
introduction  rules  for  the  semantic  apply  function;  otherwise  it  attacks  the  subgoal  with 

obj_tac. 

val  step_tac  =  eval_step_tac  ORELSE' 

apply_tac  ORELSE'  obj_tac; 

The  higher-level  tactic  evaiuate_tac  is  the  iterative  form  of  step_tac.  The  most  useful 
tactic  is  evai_tac:  this  carries  out  a  depth-first  search. 

val  evaluate_tac  =  REPEAT 1  (step_tac  1); 
val  eval_tac  =  DEPTH_SOLVE  evaluate_tac ; 


10  Elaboration  (Static  Semantics) 

The  support  for  reasoning  about  the  static  semantics  of  the  language  IF  is  set  up  along 
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very  similar  lines  to  that  for  evaluation.  Again,  we  refer  the  reader  to  the  Definition  [1] 
for  further  information. 

10.1  The  Theory  ElabObj 

The  semantic  objects  for  elaboration  are  all  defined  within  the  theory  Eiabobj,  which 
is  an  extension  of  Kernel. 

The  simple  semantic  objects  are  as  follows:  TyName  and  StrName  are  infinite  sets, 


TyVar 

type  variables 

TyName 

type  names 

StrName 

structure  names 

declared  in  Eiabobj.  The  class  TyVar,  already  defined  in  Kernel,  is  also  extensively 
used. 

The  compound  semantic  objects  ([1],  p.  17)  are  defined  as  follows 

Type  =  TyVar  LI  RecType  U  FunType  U  ConsType 

RecType  =  Lab  Type 

Funtype  =  Type  x  Type 

ConsType  =  list(Type)  x  TyName 

TypeFcn  =  {Lam}  x  list(TyVar)  x  Type 

TypeScheme  =  {All}  x  Pow(TyVar)  x  Type 

Str  =  StrName  x  Env 

TyStr  =  TypeFcn  x  ConEnv 

StrEnv  =  Strld  Str 

TyEnv  =  TyCon  TyStr 

ConEnv  =  Con  TypeScheme 

VarEnv  =  (  Var  U  Con  U  ExCon)  TypeScheme 

ExConEnv  =  ExCon  ^  Type 

Env  =  StrEnv  x  TyEnv  x  VarEnv  x  ExConEnv 

TyNameSet  =  Fin(TyName) 

TyVarSet  =  Fin(TyVar) 

Context  =  TyNameSet  x  TyVarSet  x  Env 

Again,  as  for  evaluation,  we  have  been  able  to  follow  the  Definition  extremely  closely. 
Note  the  way  that  the  compound  objects  TypeFcn  and  TypeScheme  are  defined,  using 
the  singleton  sets  {Lam}  and  {All}  as  distinguishing  labels. 
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Contexts  and  environments  are  combined  as  follows 


{T,  TJ,E)  j  {T',  U' ,  E')  =  {T  U  T',U  U  U',E]E') 

{SE,  TE,  VE,  EE)  \  {, SE TE',  VE',  EE')  =  { SE  f  SE',  TE  |  TE',  VE  f  VE' ,  EE  f  EE') 


There  are  a  number  of  predefined  quantities: 


inf  =  ( ConsType ,  0,  INT_NA ME) 
bool  =  {ConsType,  0,  BOOL_NAME) 
exn  =  (ConsType,  0,EXN_NAME) 
unit  =  {ConsType  J,  UNIT  _N A  ME) 
ti[*]to  =  {RccTypc,  {{n!,  tj),  {n2,  t2)}) 
I  NT  _N A  ME  £  TyNarne 
BOOL_NAME  £  TyNamc 
EXN _N A  ME  £  TyNarne 
UNITNAME  £  TyNamc 


The  initial  context  is  given  by  the  rules 

C0=  {T0,  U0,SE0,  TE0,  VE0,  EE0) 

Co  £  Context , 
where  : 

To  =  0 
Vo  =  0 
SE0  =  0 

TE0  =  {(( TyCon ,  UNIT),  {Lam,  Hi,  RccTypc,  0) ,0) 

((  TyCon,  BOOL),  {Lam,  0,  6oo/), 

{ {{Con,  true),  bool),  {{Con ,  false) ,  bool) }), 

{{TyCon,  INT),  {Lam,  0,  m/),  0), 

(( 'TyCon,  List), 

{Lam,  {alpha},  ConsType,  {{TyVar,  alpha),  0),  LIST_NAME), 
{{{Con,  nil),  {All,  {  alpha},  { ConsType ,  {{TyVar,  alpha)  ,0),  List))), 
{{Con,  CONS),  {All,  {alpha},  { FunTypc ,  {{TyVar,  alpha)  [*],))))} 
{ConsType,  {{  TyVar,  alpha),  0),  List), 

{ConsType,  {{TyVar,  alpha),  0),  List))))}), 

{{TyCon,  EXN),  { La rn ,  0 ,  eo-??),0}} 
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VEo  =  {((  Var,  plus),  (All,  0 ,  FunType ,  m<)), 

((Var,  minus),  (All,  0 ,  FunType,  int[*\int,  int )), 

(( Var ,  times),  (All,  0,  FunType ,  int[*\int ,  int)), 

((Var,  zero),  (All,  0,  FunType,  int,  bool)), 

((Var,  not),  (All,  0,  FunType,  bool,  bool)), 

(( Var,  head),  (All,  {alpha},  FunType, 

( ConsType ,  ((TyVar,  alpha),  0),  List) ,  (Ty Var,  alpha))), 

((  Var,  tail),  (All,  {alpha},  FunType , 

(ConsType,  (( TyVar,  alpha),  0),  List), 

( ConsType ,  ((TyVar,  alpha),  0),  List)))), 

(( Var,  null),  (All,  {alpha},  FunType, 

( ConsType ,  ((TyVar,  alpha),  0),  List),  bool)), 

((Con,  true),  (All,  0,  bool)), 

((Con,  false) ,  (All,  0,  bool)), 

((Con,  nil),  (All,  {alpha} (ConsType,  ((TyVar,  alpha),  0),  List))), 
((Con,  CONS),  (All,  {alpha},  (FunType,  (TyVar,  alpha) [*], 

( ConsType ,  ((TyVar,  alpha),  0),  List), 

( ConsType ,  ((TyVar,  alpha),  0),  List))))} 


EEO  =  0 

Polymorphic  type  inference  is  an  important  and  difficult  aspect  of  the  elaboration  of  SML 
phrases.  A  considerable  amount  of  machinery  is  needed  to  allow  sound  polymorphic 
typing. 

Type  schemes,  i.e.  types  quantified  over  type  variables,  are  used  to  capture  polymor¬ 
phism.  For  example,  the  elaboration  of  the  function  Id  defined  by 

val  Id  =  fn  x  =>  x 

results  in  the  type  environment 

{(Id,  Va.a  — +  «)} 

In  general,  if  a  is  a  type  scheme  is  of  the  form: 

a  =  \/a^...an.r 

then  t'  is  an  instance  of  a,  written  a  y  r'  if 

r  -  r{r1/ai,...,Tn/an} 

Different  occurrences  of  a  variable  may  have  different  instances  of  the  same  type 
scheme.  Thus,  in  id  (id),  the  first  occurrence  of  id  has  the  type  (a  ->  a)  ->  (a  -->  ct) 
and  the  second  has  type  a  — >  a.  Each  is  an  instance  of  Vo. a  — >  a 
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In  order  to  preserve  the  soundness  of  the  type  inference  system  for  SML,  the  elaboration 
of  VaUiind  must  make  use  of  closure  operations  in  order  that  type  variables  can  be 
used  polymorphically  (see  Rule  17  in  the  Definition  [1]).  Note  that  this  closure  is  not 
to  be  confused  with  the  function  closures  needed  for  successful  evaluation  of  function 
expressions  at  call  time. 

If  t  is  a  type,  and  A  a  semantic  object,  we  define 

close a(t)  =  Vo^.r  where  =  tyvars{r)\tyvai's{A ) 

where  tyvars(A)  denotes  the  set  of  type  variables  which  are  free  in  A.  If  the  range  of 
a  variable  environment  VE  contains  only  types,  we  set 

Close y\(  VE)  —  {{id,  close a{t))i  VE(id)  =  r) 

(this  is  naturally  extended  to  Closer  (E),  where  E  is  an  environment). 

How  is  all  this  represented  in  ZF?  We  represent  the  type  scheme 

V  ft  /  . .  ■  ft  •  T" 

as  the  ZF  tuple 


{All,  {qj,  t) 

The  following  rules  specify  when  a  type  can  be  an  instance  of  a  type  scheme. 


{All,  0,  r)  >-  t 
{All,  A,  y  u 

{All,  cons{a,  A),  r({TyVar,  a)))  y  u 
The  following  rules  define  tyvars(A): 

tyvo rs  ( 7 y  Va r ,  a )  =  { o  } 

tyvars  {  Eun  Type,  r,  r;)  =  tyvars  r  U  tyvars  t' 

tyvnrs {lice Type ,  0)  =  0 

tyvars{IiecTypr:,  cons{{l(ibel,T ),  r)) 

=  tyvars  r  U  tyvars  ( RccType ,  r) 
tyvars  {Cons']  y  pc ,  0,  tynarne )  =  0 
tyvars  {Con  slype ,  {t,  t 

=  tyvars  rU  tyvars  ( ConsTypc,r' ,tyname ) 
For  type  schemes  and  type  functions,  we  have 

iyvars{All ,  A,t)  =  tyvars  (r)  \  A 
tyvars  {{Lam ,  A,  r),  CE)  =  tyvars  (r)  U  tyvars  CE  \  A 
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For  environments  and  contexts  the  rules  are 

Tyvars  0  =  0 

Tyvars  cons(((Index,x),r ),  VE )  = 
tyvars  r  U  Tyvars  VE 

Tyvars  cons(((TyCon,tycon) ,0,  CE) ,  TE)  = 
tyvars  0  U  Tyvars  C  E  U  Tyvars  TE 
Tyvars(c ,  cs)  =  Tyvars  c  U  Tyvars  cs 

Now  we  can  compute  closures  via 

close(A,  (All,  0,  r))  =  (All,  tyvars  r  \  Tyvars  A,  r } 

Close(A,  0)  =  0 

Close(A,  cons((ide,r) ,  VE))  = 

cons((ide,  close(A,r)),  Close(A ,  VE)) 

We  also  need  a  rule  for  carrying  out  substitutions.  The  formula  subst.  (r[r'  ja\,  r")  is 
true  when  t"  is  the  result  of  substituting  r'  for  the  type  variable  a  in  the  type  r.  The 
rule  is  conveniently  obtained  by  use  of  Isabelle’s  meta-level  functions  in  the  form 

subst  (r((TyVar,  a))[r'/a],r(r/)) 

Although  this  is  very  simple  formulation,  and  has  always  worked  in  our  examples,  it 
has  the  disadvantage  of  requiring  that  the  meta-level  substitution  works  correctly  for 
occurrences  of  the  subexpression  (TyVar,a)  .  An  alternate  way  of  specifying  subst 
would  be  to  provide  explicit  recursion  equations. 

Reasoning  about  semantic  objects  is  carried  out  by  the  following  ML  functions: 

obj_step_tac  :  int  ->  tactic 
obj_tac  :  int  ->  tactic 

The  code  will  not  be  given  here.  However,  we  note  that,  if  obj_step_tac  is  unable 
to  make  progress,  then  it  replaces  each  scheme  variable  representing  a  type  variable 
name  by  a  constant.  This  is  done  throughout  the  proof  state,  by  means  of  the  function 
set_ tyvars  :  thm  ->  thm.  If  in  a  given  theorem  th  there  are  n  such  ‘unknown’  type 
variables  of  the  form  ( TyVar,?v ),  then  set_ tyvars  th  is  the  theorem  which  results 
from  replacing  these  by  the  distinct  type  variables  (TyVar,aJ,  ...,(TyVar,an).  This 
is  done  to  capture  ML’s  polymorphic  type  inference  within  our  Isabelle  theory.  An 
example  is  given  later  in  the  paper. 

Finally,  obj_tac  uses  depth-first  search  to  solve  a  particular  subgoal. 

val  obj_tac  =  DEPTH_SOLVE_l  o  obj_step_tac; 

10.2  The  Theories  ElabAtExp,  ElabProgram 

10.2.1  Inference  Rules 

As  with  the  dynamic  semantics,  the  static  semantics  inference  rules  for  E  are  easily 
given  in  Isabelle. 
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The  theories  EiabExp,  ...  ,  EiabProgram  form  a  linear  chain  extending  Eiabobj.  Below, 
we  give  the  detailed  rules  for  the  theory  EiabExp  (Rules  1-7  in  the  Definition)  — 
compare  these  with  the  corresponding  evaluation  rules  from  EvaiExp  given  above  in 
9.2. 


ini  =  / 

C  b  scon  n  =$>  t 


(Scon 


{3T  U  S1C  VIC  ICIC.C  =  (7',  (I,  SIC.  TE ,  VE,  EE)  A 

V  E'{V  ar,  x)  =  s  A  s  y  t) 

C  b  var  x  =>  t 

(3T  IJ  SE  VE  ICIC.C  =  { T,  U,  SE,  TE,  VE,  EE)  A 

V  1C’ {Con,  c)  =  s  A  s  y  t) 

C  b  con  c  =>  / 

(3T  U  SE  VE  ICIC.C  =  (71,  /  /,  ,S7b  TE,  VE,  EE)  A 
V ICL{ ICxC on,  c)  =  s  A  s  y  t) 


(Var  $) 


(Con  |t) 


C  b  excon  c  =A  t 


(ExCon  |t) 


{Hc.cTypc.,%)  =  i 


(Em  ply  Record  |t) 


C  b  {{}}  =>  /  v  1  ' 

( 3rcctypc.C  b  exprow  =P  rcciypc  A  (Hcctypc,  rcctype)  —  t) 

C  b  {  { cxpvmc ) }  =y  i 

(3E  C’.C  b  (Ire  =»  E  A  C  t  {(),  0,  E)  =  C  A  C  b  exp  =»  t) 
C  b  let  dec  in  c.rp  end  =>■  / 

c  b  exp  =>  / 


(Record  |t) 


(Let  |t) 


C  b  (  —  exp  -)  =>  / 


(Bracket  |t) 


The  following  rule  is  important  for  type  inference: 

(3  VE  VE ’  VIC" .  C  b  v  a  lb  in  d  =>  VE  A  VE  =  VE’ 
A  Closed  VE’)  =  VE"  A  {0,0,  VE",  0)  =  E) 
C  b  val  valbind  =>  E 

10.2.2  Introduction  Rules 


(Val  $) 


As  with  evaluation,  we  need  to  make  certain  equality  substitutions  in  the  two-way  rules 
capturing  the  static  semantics.  Again,  intr_ruies  denotes  the  list  of  all  introduction 
rules  for  the  evaluation  of  language  sequents.  These  are  supplemented  by  the  following 
special  rules 


((  Var,  x),  v)  £  VE0  s  y  t 
Co  b  var  x  =>  t 


(Varjnit) 


((  Var,  plus),  All,  0 ,  CunTypc,  {IlccTypc,  {(«/,  ini),  { n 2,  ini)}),  ini)  £  V Eq 
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{( TyCon ,  INT),  {Lam,,  0 ,  int),  0)  G  TE0 


Later  on  we  shall  need  the  introduction  rules  for  Let  and  Vat.  They  are  as  follows: 

C  b  dec  =*  E  C  ]  {0,0,  E)  —  C'  C' \~  exp  =>  t 


C  b  let  c?ec  in  e:rp  end  =^>  r 

C  b  valbind  ^  VE  VE  =  VE'  Closec  =  VE" 
(7  b  val  valbind  =>■  {0,0,  VE" ,  0) 


(Letl) 

(Vail) 


10.3  Proof  Procedures 

The  Isabelle  proof  procedures  for  elaboration  are  analogous  to  those  for  evaluation. 
Polymorphic  type  inference,  as  one  would  expect,  requires  special  handling.  However, 
the  actual  work  of  inferring  the  most  general  type  of  an  expression  is  aided  by  Isabelle’s 
scheme  variables,  which  can  then  be  instantiated  to  type  variables. 

The  proof  procedures  for  elaboration  are  aimed  at  establishing  the  truth  of  sequents 
of  the  form 


C  b  phrase  =>  result 

in  which  C  is  a  (fixed)  context;  phrase  is  an  expression,  declaration  or  program;  and 
result  may  be  unknown. 

The  basic  Isabelle  step  tactics  for  elaboration  are: 

elab_step_tac  :  int  ->  tactic 
step_tac  :  int  ->  tactic 

The  aim  of  eiab_step_tac  is  to  apply  one  of  the  introduction  rules  for  sequents,  in  a 
controlled  fashion.  The  code  is  analogous  to  evai_step_tac  and  will  not  be  given  here. 
The  code  for  step_tac  is  deceptively  simple: 

val  step_tac  =  (FIRSTGOAL  elab_step_tac )  ORELSE  obj_tac  1; 

It  tries  to  apply  eiab_step_tac  to  the  first  subgoal  for  which  this  tactic  succeeds.  If 
this  is  not  possible,  it  attacks  the  subgoal  1  with  obj_tac.  This  is  a  different  approach 
from  that  used  for  evaluation,  where  subgoal  1  is  the  only  one  attacked.  The  reason 
for  the  difference  is  that  the  rule 

(3C'.C  f  {0,  0,  0,  0,  VE,  0)  =  C'kC'  b  valbind  =>  VE)  . 

C  b  rec  valbind  =>  VE 

actually  allows  us  to  infer  the  resulting  variable  environment  VE  in  a  recursive 
declaration!  Therefore,  some  semantic  goals  must  remain  untouched  until  further 
instantiations  have  been  made;  hence  the  use  of  firstgoal. 

As  for  evaluation,  eiaborate_tac  is  the  iterative  form  of  step_tac. 

val  elaborate_tac  =  REPEAT 1  (step_tac  1) ; 
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The  tactic  eiab_tac  itself  does  not  require  a  depth-first  search,  but  simply  tidies  up  any 
floating  unknown  type  variables. 


val  elab_tac  =  elaborate_tac  THEN  set_tyvars_tac ; 

where 

val  set_tyvars_tac  =  Tactic 
(fn  state  =>  (marker  :=  1; 

tapply  (TRY  (PRIMITIVE  set_tyvars) ,  state) ) ) ; 


11  Examples  of  Proofs 

To  illustrate  our  proof  strategies,  we  shall  show  how  our  proof  procedures  handle  the 
simple  SML  expression 

let  val  Id  =  fn  x  =>  x  in  Id  end 

The  function  Id  has  polymorphic  type  a  — >  a.  We  consider  first  the  evaluation  of  this 
expression,  which  is  straightforward,  and  then  discuss  its  elaboration,  which  is  more 
complex,  owing  to  the  need  to  compute  closures  of  types  and  carry  out  the  correct 
polymorphic  type  inference. 

11.1  Evaluation  of  The  Identity  Function 

First  of  all,  we  describe  some  of  the  proof  steps  which  the  tactic  evai_tac  uses  to 
automate  the  evaluation  of  the  identity  function  in  the  initial  environment  Eq. 

We  begin  by  setting  the  goal  to  be  proved: 


Level  0 

E(>  h  let  val  Id  —  fn  x  —>  x  in  Id  end  =>?v 
I .  E0  h  let  val  Id  =  fn  x  =>  x  in  Id  end 

Isabelle  prints  the  level  of  the  current  proof  state,  with  the  numbered  subgoals  appeared 
underneath  the  goal  to  be  proved.  To  improve  clarity  and  readability,  we  shall  present 
the  output  from  Isabelle  in  a  ‘sanitised’  way.3 

Note  that  eval_tac  would  solve  this  goal  immediately,  but  we  shall  work  through  some 
of  the  proof  steps  to  illustrate  how  evai_tac  works. 

As  described  earlier,  the  first  phase  of  the  proof  strategy  is  the  repeated  application  of 
language  inference  rules,  choosing  the  first  subgoal  containing  a  sequent,  but  avoiding 
those  with  indeterminate  sequents. 

The  goal  is  of  the  form  E  F  let  dec  in  exp  end  =>?v.  We  therefore  apply  the  intro¬ 
duction  rule  Let,  I  from  Section  9  to  get  three  subgoals.  The  first  subgoal  calculates  the 
environment  arising  from  dec,  the  second  overwrites  the  initial  environment  with  the 


Wc  have  taken  the  liberty  of  dropping  the  var  in  expressions  like  val  var  Id  —  ....  cleaning  up  the  names  of  some  scheme 
variables  generated  during  the  proof,  and  using  various  (non-ASCII)  Greek  and  mathematical  symbols. 
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new  one,  and  the  last  elaborates  exp  in  the  resulting  environment: 

Level  1 

Eo  b  val  Id  =  f n  x  =>  x  in  Id  end  =>?v 

1.  Eo  b  val  Id  =  f n  x  =>  x  =>1E' 

2.  E0 f  IE'  =1E" 

3.  IE"  b  Id  =>?v 

The  first  subgoal  is  a  Val  declaration,  so  we  use  Vail  (see  Section  9),  to  obtain 
Level  2 

Eo  b  let  val  Id  =  fn  x  =>  a;  in  Id  end  =4? v 

1.  Eo  b  Id  =  fn  x  —>  x  =>?  VE 

2. Eoi(0,?VE,0)  =?E" 

3.  ?£"  b  Id 

We  continue  with  this  process  until  no  more  language  sequents  remain: 

Level  3 

Eo  b  let  val  Id  =  fn  x  =>  x  in  Id  end  =>?v 
1.  ( VEo  f  {{Id,  closure{x  —>  x,  Eo,  0)}})(ld)  —Iv 

Note  the  fact  that  the  value  recorded  in  the  environment  for  the  identity  function  is  the 
function  closure  closure(x  =>  x,  Eo,  0),  which  records  information  about  the  function 
necessary  to  evaluate  calls  to  it  correctly. 

Making  use  of  rules  for  applying  overwrites,  the  proof  is  complete: 

Level  4 

Eo  b  let  val  Id  =  fn  x  =>  x  in  Id  end  =4* 
closure(x  =>  x,  Eo,  0) 

No  subgoals! 

The  one-step  proof  of  this  using  evai_tac  took  0.4  seconds.4 

11.2  Elaboration  of  The  Identity  Function 

The  elaboration  of  the  identity  function  (in  the  initial  context)  is  more  involved.  This 
time  the  goal  is: 

Level  0 

Co  b  let  val  Id  —  fn  x  =>  x  in  Id  end  =>?r 
1 .  Co  b  let  val  Id  —  fn  x  —>  x  in  Id  end  =4>? r 

The  goal  is  of  the  form  C  b  let  dec  in  exp  end  =*?r.  We  therefore  apply  the 
introduction  rule  Letl  (Section  10)  to  get  three  subgoals.  The  first  subgoal  calculates 

4  The  timings  given  in  this  paper  are  for  a  Sparc  10  workstation  with  64  MB  of  RAM. 
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the  environment  arising  from  dec,  the  second  overwrites  the  initial  context  with  this 
environment,  and  the  last  elaborates  exp  in  the  resulting  context: 

Level  1 

Co  b  let  val  Id  —  f n  x  =>  x  in  Id  end  =>?r 

1 .  Co  b  val  Id  =  fn  x  =>  x  =$!E 

2.  Co  f  {0,0,  IE)  =!C' 

3.  1C'  b  Id  =y!r 

The  first  subgoal  is  a  Val  declaration,  so  we  use  Vail  (Section  10).  This  rule  decomposes 
the  result  of  the  declaration  as  a  closure  with  respect  to  the  initial  context  Co.  This 
results  in  three  new  subgoals  (1-3  below).  The  subgoal  involving  an  overwritten  Co 
changes  to  a  new  subgoal  (4)  reflect  the  instantiation  of  IE  to  the  tuple  {0,0,1  VE" ,  0), 
and  the  third  subgoal  is  carried  over  unchanged  (as  subgoal  5). 


Level  2 

Co  b  let  val  Id  —  fn  x  —>  x  in  Id  end  =>?r 

1.  Co  b  Id  —  fn  x  =>  x  =$1  VE 

2.  1  VE  =1  VE’ 

3.  Close  {Co,  1VE')  =?  VE" 

4.  C0]  {0,0,  0,0,1  VE",0)  =1C 

5.  C  b  Id  => It 

We  continue  with  this  process  until  no  more  language  sequents  remain: 

Level  3 

Co  b  let  val  Id  =  f n  x  =>  x  in  Id  end  =>?r 

1.  C0  f  ( 0 ,  0,  0,  0,  { {x,  All,  0,  ?r')},  0)  =1C\ 

2.  1C’  =  (?  T,  1 U,  1SE,  1 TE,  1  VE,  1EE) 

3.  ?V7f(;r)  —lex 

4.  lex  ylr" 

5.  {  {id,  All,  0 ,  FunTypc,  It',  It")]  =1VE’ 

6.  Close (C0,l  VE')  =?  VE" 

7.  C0  j  (0,0,0,0,!VE",0)  =!C' 

8.  1C'  =  (?  T’,  1 U',  1SE',  1  TE',  1  VE',  1  EE') 

9.  ?  VE'(Id)  —la' 

10. ? cr7  ylr 

At  this  stage,  we  have  removed  all  of  the  language  reasoning,  and  all  that  is  required 
is  to  prove  the  remaining  semantic  subgoals. 

Expanding  the  context  Co,  and  simplifying  gives 
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Level  4 

Co  t~  let  val  Id  =  f n  x  =>  x  in  Id  end  =^?r 

1.  (VEo\{(x,AU,0,1t')}(x))  =?a 

2.  ?<r  X?t" 

3.  { (/c?,  yl//,  6?,  Tt-7,  ?t,;) }  =IVE' 

4.  Close(CoCVE')  =?VE” 

b  .Co\(0, 0,0,0, !VE",0)  =1C' 

6.  ?  C1  =  (IT',W',1SE',1TE',IVE',IEE') 

7.  ?  VE'(Id)  =?<j 

8. ?cr'  >-?r 

Using  overwrite  apply  rules,  as  well  as  the  rule  for  trivial  instances  of  type  schemes, 
we  obtain: 

Level  5 

Co  L  let  val  Id  =  f  n  x  —>  x  in  Id  end  =^?r 

1.  Close(Co,  {(Id,  All,  0,  FunType,  ?r',  ?r')})  =?  VE" 

2.  Co]  (0,0,0,0,IVE",0)  =?C" 

3.  IC  =  (?  T\  ?  C/;,  ?5£?',  ?  TE\  ?  ?^'> 

4.  ?  VE'(Id)  =?a' 

5. ?cr'  X?r 

The  new  first  subgoal  needs  careful  handling.  When  we  unravel  the  various  rules  for 
the  Close  operation,  we  eventually  reach  the  following: 

Level  6 

Co  H  let  val  Id  =  f n  x  —>  x  in  Id  end  =4>?r 

1.  tyvarsilr')  —I A 

2.  tyvars(Co)  =7B 

3.  (All, IB,  Fun  Type,  It1, It')  =la' 

...  (other  subgoals) 
n .la'  y?r 

We  have  now  reached  a  critical  point.  We  can  see  from  subgoals  3  and  n  that  Id  is 
going  to  have  a  function  type  of  the  expected  form  It'  — >?t'.  However,  to  make  further 
progress,  the  ‘unknown’  type  It'  must  be  instantiated;  eiab_tac  does  this  automatically, 
replacing  it  by  a  type  variable  such  as  a!  In  other  words,  at  this  point  eiab_tac  infers  the 
polymorphic  type  for  the  identity  function.  This  will  allow  tyvars(lT')  to  be  calculated, 
and  the  proof  can  progress.5  The  instantiation  gives: 

5  It  should  be  noted  that  in  more  complicated  cases,  where  the  same  polymorphic  function  is  instantiated  with  several  different 
types  within  the  same  expression,  the  scheme  variable  may  occur  elsewhere  in  a  subgoal  in  such  a  way  that  it  cannot  be  instantiated 
here  to  a  type  variable  (for  example  it  may  end  up  being  a  function  type).  The  tactic  therefore  checks  that  the  scheme  variable  to 
be  instantiated  does  not  occur  as  a  right  hand  side  of  a  later  subgoal. 
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Level  7 

Co  b  let  val  Id  =  f n  x  =>  x  in  Id  end  =^?r 

1.  tyvors(a)  =? A 

2.  tyvars(Co)  =? B 

3.  (All,  ?/i,  FunTypc,  a,  q) 

....(oilier  subgoals) 

n.  ? rb  >-?t 

The  rest  of  the  proof  is  straightforward.  Using  the  following  facts: 

tyvars(a)  =  {a} 
tyvars(Co)  =  0 

along  with  some  trivial  set-theory,  we  eventually  have 
Level  8 

Co  h  let  val  Id  =  f n  x  =>  x  in  Id  end  =$-(FunType,a,ac) 

No  subgoals! 

This  result  takes  1.9  seconds  to  prove  in  one  step,  using  elab_tac. 

In  Section  10  we  discussed  the  following  expression,  in  which  the  identity  function  is 
applied  to  itself: 

let  val  Id  =  fn  x  =>  x  in  Id  (Id)  end 

.  Without  working  through  the  automated  proof  which  carries  out  its  type  inference, 
we  recall  that  each  occurrence  of  Id  in  this  example  is  a  different  instance  of  the  same 
type  scheme.  Our  proof  procedure  elab_tac  correctly  deals  with  this  possibility,  and 
automatically  gives 

Level  1 

Co  b  let  val  Id  =  f  n  x  =>  x  in  Id(Id)  end  =$>(FunType ,  a,  a) 

No  subgoals! 

This  proof  involves  a  large  number  of  inferences,  taking  2.3  seconds. 

12  Conclusions  and  Suggestions  for  Future  Work 

We  have  described  a  method  for  reasoning  about  operational  semantics  within  the 
Isabelle  theorem  prover.  The  Elle  system,  for  reasoning  about  Standard  ML  programs, 
has  also  been  described. 

In  other  work  by  the  authors  [30],  the  role  of  denotational  semantics  in  the  verification 
process  was  discussed,  and  a  possible  mechanisation  explored  in  the  HOL  system.  It 
is  instructive  to  compare  the  two  approaches.  We  believe  that  the  present  work  shows 
the  greater  flexibility  and  usefulness  of  the  operational  semantics  approach  as  a  means 
of  defining  the  meaning  of  language  constructs. 
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We  believe  that  the  present  work  will  benefit  a  number  of  people.  It  should  be  of  help 
to  beginners  trying  to  understand  the  Definition  of  SML,  as  well  as  to  implementers. 
It  can  assist  experts  who  wish  to  explore  possible  design  changes  and  extensions  to 
the  language,  by  aiding  reasoning  about  how  the  various  phrases  will  interact.  We  also 
believe  that  the  system  will  benefit  those  interested  in  operational  semantics  as  a  basis 
for  program  verification,  equivalences  and  transformations. 

The  Elle  system  is  easy  to  modify,  and  is  quite  efficient,  because  it  exploits  Isabelle’s 
liking  for  inference  rules,  and  keeps  costly  rewriting  to  a  minimum. 

The  user  interface  is  still  under  development.  Ideally,  it  should  offer  the  user  a  range  of 
choices.  A  minimal  interface  would  be  to  mimic  that  of  an  ML  interpreter,  presenting 
only  the  value  and  type  of  the  most  recently  declared  variable(s).  The  maximal  interface 
would  be  to  describe  fully  the  proof  of  each  sequent,  showing  also  the  environment  (or 
context)  before  and  after  the  evaluation  (or  elaboration).  This  information  can  quickly 
become  too  much  to  cope  with.  Work  is  progressing  on  capturing  the  Elle  system 
within  the  Xlsabelle  interface  mentioned  earlier. 

Further  work  needs  to  be  done  to  extend  the  system  to  allow  for  a  larger  subset  of 
SML.  Exceptions  and  imperative  features  will  require  proper  handling  of  the  state  and 
exception  conventions  [1,  29],  while  the  inclusion  of  the  modules  system  would  allow 
experiments  with  subtle  aspects  of  signature  matching  and  elaboration  of  functors  and 
signature  expressions. 

Another  interesting  extension  is  to  general  proofs  of  correctness  of  algorithms  written 
in  SML,  for  which  we  need  to  have  an  expressive  specification  language.  Since  our 
system  is  built  on  Isabelle’s  version  of  ZF  set  theory,  we  already  have  the  basis  of 
such  a  language.  Such  specification  constructs  are  under  investigation  as  part  of  the 
Extended  ML  language  of  Sannella  and  Tarlecki  [31],  and  in  current  work  of  Gene 
Rollins,  Jeannette  Wing,  and  Amy  Moormann  Zaremski  at  CMU  on  Larch/ML  [32]. 

Reasoning  about  program  equivalences  and  transformations  [33,  34]  is  also  an  important 
line  of  investigation.  The  operational  semantics  rules  which  define  SML  have  already 
been  expressed  in  a  two-way  form  which  will  facilitate  such  reasoning. 

Our  methods  will  apply  well  to  concurrency,  where  operational  semantics  is  frequently 
used  to  give  the  meaning  of  language  constructs:  possibilities  include  CML  [35], 
CCS  [9]  and  the  tasking  model  of  Ada. 

Finally,  we  believe  that  the  approach  will  be  beneficial  in  reasoning  about  properties  of 
formal  specifications  in  languages  such  as  Z,  whose  semantics  can  be  described  by  a 
proof  theory  such  as  W  [11].  Preliminary  investigations  have  been  carried  out  in  this 
area;  however,  the  task  of  capturing  the  semantics  of  the  Z  language  in  a  proof  assistant 
remains  a  formidable  task.  It  is  not  clear,  for  example,  how  to  provide  a  consistent 
yet  simple  enough  model  for  Z  schemas  and  schema  operations.  Schema  quantification 
is  especially  tricky. 
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APPENDIX  A 
The  Theory  Tags 

The  theory  Tags  is  an  extension  of  zf,  designed  to  meet  the  need  for  built-in  distinct 
variables.  It  defines  two  new  constants,  black  and  white,  of  meta-type  i  =>  i  (i.e.  which 
take  sets  to  sets)  as  follows: 

black(k)  =  (0,  k) 


white(k)  =  (succ(0),k) 


The  following  rules  can  easily  be  derived: 

black(m)  =  black  (n) 


white(m)  =  white(n) 


(blackjnject) 


(whitejnject) 


white(m)  =  black(n)  ,  .  .  ,  .  .  . 

- — — - —  (wmte_neq_black) 


white(m)  =  0 


black(m)  =  0 


(white_neq_0) 


(black_neq_0) 


For  each  member  id  of  the  set  I  of  identifier  classes,  we  declare  id  as  a  set,  and  posit 
an  injection  injd  :  i  i  which  satisfies  the  rules6 


in_id(m)  =  in_id(n' 


m  =  n 


in_id(m)  €  id 


-  (in_id_inject) 
(in_id_type) 


Then,  for  each  proposed  variable  name  of  class  id,  we  declare  it  as  a  constant,  and 
construct  a  parse  translation  which  gives,  as  the  internal  representation  of  this  variable, 
a  unique  term  made  up  of  successive  applications  of  the  operators  black  and  white. 
This  is  done  in  such  a  way  as  to  guarantee  the  mutual  distinctness  of  all  such  defined 
variables,  by  means  of  standard  proof  techniques  using  the  above  rules.  Print  translations 
are  also  needed,  to  ensure  that  these  terms  correctly  print  back  to  the  expected  form. 
We  shall  not  go  into  the  details  of  these  parse  and  print  translations  here. 


6  Note  that  the  rule  in_id_type  should  restrict  the  m  to  come  from  some  explicitly  constructed  set,  otherwise  id  itself 
will  be  “too  big”  to  be  constructed  in  ZF.  This  would  be  done  most  suitably  using  the  theory  of  Inductive  Definitions  in  Isabelle 
ZF.  However,  we  have  not  done  this,  because  the  whole  Tags  theory  is  quite  peripheral  to  the  main  Elle  develoment,  and  there 
may  be  other,  simpler,  ways  to  ensure  that  the  desired  identifiers  are  distinct. 
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